You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Tobias Schöneberg <t....@metas.de> on 2016/03/01 14:47:58 UTC
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
RE: Asking for comments about cxf-rs with oneway jms transport
Posted by Andrei Shakirin <as...@talend.com>.
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:t.schoeneberg@metas.de]
> Sent: Dienstag, 1. März 2016 14:48
> To: users@cxf.apache.org
> 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
Re: Asking for comments about cxf-rs with oneway jms transport
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/