You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Ranx <br...@mediadriver.com> on 2016/02/27 05:03:04 UTC
CXF server versus endpoints
We are in the process of creating a number of services that will share many
characteristics such as security, logging and so on and it would be great if
we didn't have to replicate a lot of it.
<cxf:cxfEndpoint id="myFooService" address="${CXFServer}/services"
serviceClass="${serviceClass}" loggingFeatureEnabled="true"
loggingSizeLimit="20">
<cxf:binding> <soap:soapBinding version="1.2" /> </cxf:binding>
<!-etc->
</cxf:cxfEndpoint>
Things like the SOAP binding version, logging interceptors, etc. will be
common among all of these independent of their service class. But I can't
seem to find a good example that illustrates setting that up. I'm sure it's
there I probably just searched with the wrong name. Perhaps its on cxf bus?
--
View this message in context: http://camel.465427.n5.nabble.com/CXF-server-versus-endpoints-tp5778342.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CXF server versus endpoints
Posted by Brad Johnson <br...@mediadriver.com>.
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 <sb...@gmail.com>
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/
>
Re: CXF server versus endpoints
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/
Re: CXF server versus endpoints
Posted by Brad Johnson <br...@mediadriver.com>.
Anyone?
I'm using this with a Camel recipientList. I've now written an small
service invoker class which pulls the name of the service interface, the
operation name and concatenates them with bean: in order to invoke the
associated OSGi service instead of going through routes. But I'm still
left with the problem of multiple set ups of CXF endpoints with duplicated
information and I can't seem to find any good examples that don't do it
that way.
On Fri, Feb 26, 2016 at 10:04 PM, Ranx <br...@mediadriver.com> 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.
>
Re: CXF server versus endpoints
Posted by Ranx <br...@mediadriver.com>.
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.