On 15.08.2017 16:06, r...@enjekt.org wrote: Christian,
I've also seen a lot of people using Processors/Exchanges which unnecessarily couples their cod to the Camel framework. Unfortunately the Camel in Action book doesn't get around to advising against that practice until your well over 100 pages into the books. And when it does it is in a bulleted list at the end of a chapter. When I'm at client sites it's one of the first things I teach them when mentoring developers. Use POJOs and unit tests just like any other code. Unfortunately neither the Camel website nor the Camel in Action book stress this and too many code examples use Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't recall the last time I used Camel Processor/Exchange directly. I think you are on a very good track with this approach and it would be good to spread the word about it. As you wrote it is not emphasized enough in the camel book. So if you have a blog that would be a great theme. But services aren't more loosely coupled than messaging. If I have bundle A with all its classes unexported in ".internal" package and bundle B in the same situation but they communicate via Camel routes, that's decoupled at compile time and at runtime. Injecting a service interface whether it is through a proxy or not couples the two bundles at compile time and temporally couples them at runtime. If one puts the service interface into a separate bundle one now has a different dependency. Communicating externally is of course very loosely coupled. On the other hand remote communication is typically a lot more expensive than local communication using an OSGi service. Another problem with remote communication is also that it tends to make your domain model anemic. For the remote communication you need simple DTO like classes. So the logic is typically separated from the data. If this really is a problem typically depends on how complex your domain is. Your approach sounds a lot like a typical microservice approach. What I currently look into is combining domain driven design and microservices. I found that making each service in a bounded context a microservice is creating a lot of overhead. Instead I think it makes sense to use OSGi services to talk between bundles of the same bounded context. The border services that form the outside view of the bounded context are a good match for the camel endpoints you are using. Btw. What type of communication do you use? REST or more message based? One other thing I am looking into is how to separate the user code from the transport protocol. For this case jax-rs-whiteboard or Aries RSA with CXF might be interesting for you if you use REST or SOAP. It allows to offer and consume services without a direct dependency to camel or CXF. Unfortunately we do not yet have a good solution for one way messaging based communication / eventing. best regards Christian -- Christian Schneiderhttp://www.liquid-reality.de Open Source Architecthttp://www.talend.com -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
