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 < [email protected]> 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 > >
