Hi Tobi
Using CXFRS client with JMS is indeed uncommon with the main reason
being is that of course CXFRS is primarily meant to work with the HTTP
targets.
But with CXF being so flexible it ended up supporting non-HTTP targets
too with some minor updates.
So, ultimately, as far as the task of delivering a message over JMS is
concerned, one has a choice to use JMS directly. Or, with CXF, use
either SOAP (not unusual) or as in this case RS clients - where the
client works with an Http centric API but ends up sending a message over
JMS.
If you use the RS proxies (as opposed to WebClient) then it will be less
obvious what transport is being used, and can be a reasonable compromise
as far as the 'mis-use' of the API is concerned
Thanks, Sergey
On 01/03/16 13:47, Tobias Schöneberg wrote:
Hi,
this morning I created this issue (which is already solved, thx again):
https://issues.apache.org/jira/browse/CXF-6810.
Note that in a comment, Sergey Beryozkin writes
"So now we have WebClient and proxies being able to use HTTP Api to send the
messages over JMS which is unusual ;-)"
Because I'm new to cxf, I would like to ask the community whether they think
I'm on the right track with my approach.
My usage scenario is that I have a "frontend" web-UI server running in the
cloud, that needs to exchange data with the backend ERP system.
The internet link between those two is known to be a bit shaky.
Now, what i had in mind for the solution is to run one jms-broker on the web-UI
server and one near the ERP system.
Those two brokers shall forward messages between each other and communicate via
ssl.
Both the web-UI and the ERP-system shall provide some services via cxf-rs.
Also, they both share the same service-interfaces and serializable POJOs.
The respective clients shall be able to make the invocation one-way, i.e.
without having to wait for a result.
They just shall obtain a client-proxy and make their call. The call shall
directly return with a (http-)result of 202, as described here in the docs:
http://cxf.apache.org/docs/jax-rs-advanced-features.html#JAX-RSAdvancedFeatures-Onewayinvocations.
If the internet link is currently down, that's not the client's problem, but
the two brokers need to retry and reestablish their connection.
I think that if i used the http-transport, the client would have to check the
if the request worked and explcityl retry if not.
Note that if the server-endpoint of the other party can't process the message
for whatever reason, it's also not the client's problem,
but the server-endpoint needs to store the unprocessable message and notify
someone about the problem.
I think that my scenario is not that uncommon, but aparently using
cxf-oneway-jms is uncommon.
So I wonder, is this a reasonable approach? Does cxf provide better tools for
this? Or maybe cxf is generally used for scenarios different than this one.?
Best regards
Tobi
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
