I have searched for a solution to the problem you described for a long
time now and finally found a good concept.
Cross cutting concerns can be solved using the TopologyManager in the
Remote Service Admin spec (CXF-DOSGi).
One duty of the TopologyManager is to watch all registered OSGi services
and then eventually trigger RemoteServiceAdmin to export such services.
See this tutorial for a simple example:
http://liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi
The service in the DS example leverages DOSGi to export a REST service:
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java
By default the TopologyManager only watches for services with the
property osgi.remote.interfaces but according to the spec it can react
on any service it wants.
It also can add arbitary configuration to the OSGi service properties.
One of these properties are the intents a service must support. For CXF
this translates to CXF features.
So this can be used to add cross cutting concerns like security, logging
to any service.
The CXF provider for RemoteServiceAdmin can then export and import the
OSGi services as REST and SOAP services depending on their annotations.
Unfortunately we are not yet there. The current TopologyManager impl
does not support adding cross cutting concerns but the spec fully
supports that so we can develop
such support in the future.
Christian
On 09.03.2016 16:26, Ranx wrote:
I have a client who wants to use deployable microservice bundles with
REST/SOAP APIs. Not a problem of course as it works very well.
The issue is that I'm getting a lot of boilerplate replication across the
project which is only getting to get bigger and more difficult to manage
with time.
This includes everything from basic host/port settings to security.
Obviously setting that up in every bundles is error prone (especially with
XML) and the a real headache for maintenance. Part of the problem is that
from what I've read sharing cfg files across bundles is not recommended.
Perhaps with an update strategy reload that isn't such a big deal. But it
would be nice to have something like:
com.foo.basic.rest.cfg
com.foo.basic.soap.cfg
and use that in each of my bundles to load basic configuration information.
Each bundle would still have its own cfg file that will be used for very
special and custom items.
Things like PasswordCallback and keystores are exactly the same. In the
past I've always used a gateway bundle to centralize that. I may still end
up using something like that in this project but as "microservices" become
more and more the holy grail (until it isn't anymore) this is going to be an
on-going concern.
I'm using Karaf so can also imagine using OSGi registry for creating CXF
interceptors that I might inject into the setup of each of my projects.
This problem is manifesting on the endpoints in both directions. For
example, one of the systems I'm integrating with is JDEdwards SOAP services
which require PasswordCallbacks and http conduit settings. But there are a
large number of these services with WSDLs for many aspects of inventory,
supply, invoices, etc.
--
View this message in context:
http://camel.465427.n5.nabble.com/CXF-cross-cutting-concerns-tp5778798.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
