Weird, I didn't see this last year after you posted it. I don't know why. I
was up here reading on the latest as I'm going to be doing some prototyping
with Fuse 7 and wanted to see what latest best practices are and where CDI
is after the February release date.
I probably should write a blog/tutorial on this stuff. Using Mockito to
mock OSGi injection, pojos (not Processors/Exchanges) and using standard
Camel Java DSLs and CamelTestSupport make testing simple. Part of the
problem I've found with the Blueprint implementation of Camel is if one
uses the XML the routes are stuck in the Camel context and can't be broken
down into sub-routes for easy testing. The CamelRouteBuilder mitigates that
a lot. So you get an onion peel testing of JUnit for basic handlers,
Mockito for injecting OSGi mock services, CamelTestSupport for testing the
wire up of handlers and eips with mock services (you have to use the JNDI
registry in CamelTestSupport and not the OSGi service registry), and only
use the CamelBlueprintTestSupport for a general sanity check that
everything is wired and spelled correctly.
One downside is that I end up using the Camel annotations for injection
then and not CDI or other standard. A small price I guess...I just keep
hoping we get the best of all worlds at some point with CDI for easy wire
up and DS mechanics under the covers.
For CXF services I usually use both SOAP and REST annotations on an
interface and then use a Camel route with either a recipientList using the
operation name to specify an immediate endpoint or I use the
toD(direct"${operationName}") to hit a route (I'm writing that off the top
of my head so may be misrecalling the variable). However, I've also inject
OSGi services into the CXF bundle and have every method on the web service
invoke the same direct: endpoint which has a single bean on it - the
injected OSGi service. Camel uses reflection to select the correct method
to invoke. That works as long as the requests are uniquely named. Otherwise
it's back to using the recipientList or toD variant. That means that Camel
and CXF live in one bundle and the OSGi service just gets messages. I
should mention that I usually use canonical domain objects so before the
OSGi service actually gets invoked I'm transforming using Dozer into a
canonical domain model. That way I don't get protocol/transport artifacts
like XMLGregorianCalendar leaking into the rest of the world.
But I use a variety of messaging and not just web services. That's where
routing between bundles with Camel can be quite beneficial. I might use
SEDA (VM) during development or even deployment and use a string
interpolation injected via @PropertyInject for that endpoint and set it in
the Blueprint by default but can override it in the pid.cfg file. That way
if I move a bundle the servicing bundle to another container I can change
the endpoint to a amq: or whatever else it might be. That's rare. More
usual reasons for changing it would be if the incoming event or any even is
transactional and I want to drop it on a persistent queue before returning
an ACK to the client that things are OK.
But that use case is what I meant by it being loosely coupled. If I'm using
SEDA on a route and CXF receives an incoming event, converts the object to
a domain model sans JAXB/XML elements, and then sends it on an endpoint, I
don't need to decide what the endpoint is until runtime. Default of SEDA/VM
for development and then it may or may not be the same when deployed
depending on where the consuming bundle lives.
On Wednesday, August 16, 2017 at 3:42:13 PM UTC-5, Christian Schneider
wrote:
>
> On 15.08.2017 16:06, ra...@enjekt.org <javascript:> 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.
