camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camel Guy <ca...@devguy.com>
Subject Re: Best suitable architecture using Camel
Date Wed, 18 Jun 2014 17:54:12 GMT
Do Camel components save you time? Does Camel encourage you to build
software in a way that might be constraining but also might have some
wisdom behind it? For example, do all Camel programs feel familiar?

You can only decide by riding Camel around for a while.

Is Camel better than writing traditional Spring apps? I think so, but only
because I sprinkled in functionality that all real projects need, such as
Properties files, exception handling, logging, thread pooling. Is Camel
better? Yeah. Way Better. Did I find what I needed to know in a book?
Unfortunately not. Camel in Action got me started but the community's
documentation got me finished.

Do I know when to build serializers vs. components vs. POJOs vs. Groovy?
Not really, but I usually go in the reverse order. Camel makes it easy to
throw stuff against the wall and refactor/formalize it as time goes on. No
point in building a component that you decide later you don't need.

Would I use a closed-source or for-pay tool like Camel? Not on your life.


~cg



On Wed, Jun 18, 2014 at 10:29 AM, Christian Schneider <
chris@die-schneider.net> wrote:

> Unfortunately I do not have good examples for this. My own examples are
> too small to make good business cases and the customer projects I work in
> are not open source.
> Maybe I got something more after apachecon. I submitted a talk about
> lessons learned from customer projects in the OSGi environment. There I
> plan to show some practical examples.
>
> The question whether to use a camel route with cxfrs or a cxf rest endpint
> directly is difficult to answer.
>
> For me the main deciding point is if what you build is more an application
> or more an integration. So if your effort is more around business logic and
> just a little integration then I would rather start with a cxf endpoint and
> use camel only e.g. for sending and receiving jms or files. In that case it
> might also be a good idea to package the camel stuff separately and route
> from e.g. jms to the rest service but that is another difficult choice to
> make.
> Something that also speaks for a cxf endpoint is if your rest service (as
> a java interface) has more than one method. Camel does not directly support
> more than one method. You would have to parse and route the different paths
> yourself.
>
> On the other hand if what you do is mainly integation (forwarding data
> from one point to another) then a camel route is a better choice.
>
> Christian
>
> Am 18.06.2014 07:15, schrieb techbird:
>
>  Hi Christian -
>>
>> Your guidance in the matter, is very valuable.  I'm also about to start
>> work on a large integration project using jaxrs and have been thinking
>> about the same questions.  i.e. separation of concerns, SRP.
>>
>> Could I be so kind and ask - have you written more on the subject?  Do
>> you have any examples which you'd recommend as a good reference?  Any books
>> cover this area?
>>
>> Also can I ask when implementing webservices, did you discard the idea of
>> using cxfrs?  I was thinking of using cxfrs to receive payloads, translates
>> theses to a message (a command message as such) and dispatch these to
>> routes for processing (sync, or async depending on the service type i.e.
>> short service, or workflow service).  As recommend - the business logic
>> would in POJOs as would the messages.  If the business logic need to call
>> any integration functionality, it would do so using a camel proxy (producer
>> template) against an interface.
>>
>> I guess my question is  - when would you use cxfrs for a service
>> endpoint, and when would you not use camel and use cxf (jaxrs in my case)
>> directly.
>>
>>
>>
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message