Thank you for your timely and thoughtful response Christian.
I'd love to be at your presentation - as I've been aware of your
involvement with camel for years - and know your contributions are
significant. But alas, I'll be at my desk working.
I think the important thing I'm taking away from your comments is the
concept of separation of concerns and not over-engineering a solution
using EIP. Almost keep EIP light, fresh and readable (so use for
mediation for example).
For my work, I think I'll take time and think about what you have
written, and not rush into a solution. It make sense to turn REST calls
into messages consumed by queues but how that's done needs thought. I'm
thinking through the idea of using the CQRS pattern, which is why I was
leaning towards implementing the REST endpoint in Camel.
Sincerley thank you Christian - you're one special guy, Gareth.
On 18/06/14 18:29, Christian Schneider 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.
