2015-05-20 212 views
4

我们需要保证发送Web服务请求。步骤如下:确保向Web服务发送请求

  1. 尝试将请求发送到Web服务。同步或异步请求无关紧要。
  2. 如果服务由于某种原因(例如服务不可用)而未确认请求,我们会在一段时间内再次尝试第1步(即有某种轮询)。

问题在于执行步骤#2(即轮询)。 这个用例看起来很常见,我认为应该已经有解决方案了。所以我希望只向Web服务发送一个请求,所有其他逻辑(即其保证的交付)将由某个框架执行。

你知道这样的解决方案吗?

有“Guaranteed delivery”EIP模式和骆驼支持它。但是我没有找到骆驼支持它的任何信息,以及它是否适合我们的情况。

我们的要求 - Java,SOAP,开源解决方案。 我们计划使用Apache CXF,但它并不重要。

最后的话:分别提供 2伟大的答案:

  1. 春重试布莱恩·阿格纽。这是相当普遍的方法,不仅适用于Web服务。
  2. 来自Ashok Nanda的CXF故障切换。该解决方案就Web服务而言,完全符合我们的需求。

不幸的是我不能选择两个答案作为最终让我选择了布莱恩的一个,因为它是第一个,他提供了帮我看看另一个可能的问题:-) 谢谢你们一个真正伟大的解释!

+0

我不会真的称之为“轮询”,而只是“重试”。 (请小心如何解决何时重试,请注意。)我不确定你在这里寻找什么 - 模式或库中现有模式的实现? –

回答

4

除了简单地在某种循环中编写请求,您可以查看框架,如Spring Retry

它将允许您定义您的重试策略,以考虑退避策略,超时以及何时/何时而不是尝试重试。最后的因素是至关重要的。如果您无法连接,那么重试是可行的。另一方面,如果您连接并发送请求但未能得到确认,那么您需要了解重试是否合适。 idempotency of requests的概念在这种情况下很重要。

幂等HTTP方法是一种HTTP方法,可以称为多个 次没有不同的结果。如果方法是 只调用一次或十次,这并不重要。结果应该是一样的。 同样,这只适用于结果,而不适用于资源本身。这个 仍然可以被操纵(如更新时间戳,前提是这个 信息不在(当前)资源表示中共享。

+0

感谢您的快速响应和详细的答案。它看起来像我们真正需要的。将检查它并返回到这里。 关于确认,我认为服务首先确认即将到来的请求存储在请求队列中。然后才开始处理请求。 在这种情况下,承认是我们唯一需要的。 我错过了什么吗? –

+1

这听起来正确。回覆。您的确认场景。想象一下,如果你发出你的请求,并且你在等待这个回应。一段时间后,你会超时的连接。您必须询问您是否可以重试该请求 –

4

在Apache的CXF,它是可以做到的消息传递重试时的目标端点是向下使用org.apache.cxf.clustering.RetryStrategy 类和扩展此。 请参考:http://cxf.apache.org/docs/failoverfeature.html

这是主要的运行时库CXF,CXF-RT-功能 - clustering.jar的一部分,将在OSGi的/非OSGi的或骆驼的环境甚至工作。

+0

感谢Ashok!如果有可能将2个答案标记为最终答案,我肯定也会选择你的答案。 您的建议更适合网络服务。 我已经用最终词更新了上面的描述。 –