Hi Tobias, The solution with two JMS brokers should work, alternatively I see the following options:
1) Using CXF Failover feature http://cxf.apache.org/docs/jax-rs-failover.html In this case Proxies and WebClients can be configured to failover to the same (or alternate) addresses in case of connection-related failures 2) Setup two JMS brokers like in your solution, but instead sending JMS message with CXF client directly, provide lightweight proxies exposing service JAXRS API and using JMS client in implementation on one side and using JMS listener and JAX-RS client on other side. web-UI server will interact with proxy using normal HTTP based JAX-RS API, proxy will put the message into the JMS queue, on the other side JMS listener will read the message and send it using JAX-RS client to ERP system. Option (1) is lightweight, Option (2) is more complicated as your, but provides flexibility to transparently replace JMS brokers to other technology in the future. Regards, Andrei. > -----Original Message----- > From: Tobias Schöneberg [mailto:[email protected]] > Sent: Dienstag, 1. März 2016 14:48 > To: [email protected] > Subject: Asking for comments about cxf-rs with oneway jms transport > > 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
