Sergey,
Thanks for the feedback. I'm going to be working on a large system to tie
together many disparate systems with new service interfaces with canonical
data model sets. I look at something like this with the rsServer and
cxfEndpoint and that pattern is going to be repeated a large number of
times. Which is fine as far as it goes until something has to be changed
and then every file has to be changed. I think we've all worked with large
chunks of XML and realize that once you get into it managing small changes
becomes a nightmare.
Ironically now that I've been using Camel/Fuse/Blueprint for a few years
I've lost touch with the Java underpinnings of APIs and that's a real
downside. This is the sort of thing that screams refactor/reuse through OO
patterns but I don't use ow work with CXF rsServer or endpoints directly
enough to do that.
Just as an example, one of the internal clients wanted Badgerfish. Easy
enough to add to the providers but if that became a universal standard then
I'd have to add it to every endpoint. Right now I have these in their own
web services project that is delegating out to OSGi service calls but in a
way it would be far more convenient to actually keep this in the same
bundle as the service itself. That would make the bundle a self-contained
deployable and more in the spirit of a microservice (for good or ill).
And this is a very simple example because the actual install will have
http4j set up and keystores and conduits out to other services. But I'm
not finding any good way of managing such cross cutting concerns.
Something like the http4j would be nice to set up globally but override
locally if necessary. Http conduits with callbacks will be required as
well and I'm trying to figure out a better mousetrap here.
At this point I'm looking at things like the cxf:providers and thinking
that maybe the answer is to create a CXF providers OSGi service that keeps
a collection of them internally. The same might be true of security,
interceptors, etc. But if I'd have been working more closely with the code
and less with the XML for CXF over the past few years I might actually look
at building a factory or component for the base server(s) itself in Java.
I may still do that.
The boilerplate gets a bit overwhelming. If anyone has any good
references on working with CXF server code directly to do that sort of
thing I'd appreciate it.
<reference id="InvoiceDocumentService"
interface="foo.api.InvoiceDocumentService" />
<!--
*******************************************************************************
-->
<!-- The web services endpoint setup. -->
<!--
*******************************************************************************
-->
<cxf:rsServer id="cxfRsServer" address="${CXFServer}/resources"
serviceClass="${serviceClass}" loggingFeatureEnabled="true"
loggingSizeLimit="20">
<cxf:providers>
<bean class="org.apache.cxf.jaxrs.provider.json.JSONProvider">
<property name="dropRootElement" value="true" />
<property name="supportUnwrapped" value="true" />
</bean>
</cxf:providers>
</cxf:rsServer>
<cxf:cxfEndpoint id="cxfSoapServer" address="${CXFServer}/services"
serviceClass="${serviceClass}" loggingFeatureEnabled="true"
loggingSizeLimit="20">
<cxf:binding> <soap:soapBinding version="1.2" /> </cxf:binding>
</cxf:cxfEndpoint>
<bean id="serviceInvoker" class="foo.webservice.ServiceInvoker">
</bean>
<camelContext xmlns="http://camel.apache.org/schema/blueprint";>
<!--
*******************************************************************************
-->
<!-- CXF Endpoints receive requests defined on the API interface
and then
send via a recipient list to a route with the same name as the
interface.
Both REST and SOAP requests get routed this way. -->
<!--
*******************************************************************************
-->
<route id="RESTRoutes">
<from uri="cxfrs:bean:cxfRsServer" />
<log message="Received request: ${body}" />
<log message="Received headers request: ${headers}" />
<bean ref="serviceInvoker" method="invokeServiceFromREST" />
</route>
<route id="SOAPRoutes">
<from uri="cxf:bean:cxfSoapServer" />
<log message="Received request: ${body}" />
<bean ref="serviceInvoker" method="invokeServiceFromSOAP" />
</route>
</camelContext>
On Sun, Feb 28, 2016 at 6:57 AM, Sergey Beryozkin <[email protected]>
wrote:
> Not sure about soapBinding options but you can indeed set various
> interceptors/features on a cxf:bus and then link to this bus from
> individual cxf soap endpoints
>
> Sergey
>
> On 27/02/16 04:04, Ranx wrote:
>
>> And is there a way to set that up so that the service interfaces/endpoints
>> are just a list?
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/CXF-server-versus-endpoints-tp5778342p5778343.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
