Web服务重新连接模式

本文关键字:模式 重新连接 服务 Web | 更新日期: 2023-09-27 18:08:48

我正在开发一个。net Webform应用程序,大量使用web服务与外部服务器数据库通信。

因此,我试图找到在调用WS方法时处理断开连接和失败的最佳方法。

现在,我已经为我调用的每个WS方法创建了一个代理函数(类似于一个层),它在循环中重复特定的WS调用,直到它成功输出。

对于同步和异步调用,我已经解决了我的问题,但是我在我的WebService层上增加了一个烦人的额外层,有额外的维护和大量的冗余代码。

我拒绝相信对于这种标准情况没有现成的解决方案,但是在任何地方都找不到。

任何想法?

下面是我的额外层(同步)的例子:
public static int WsMethod(string param1, int param2)
{
 while(true)
 {
  try
  {
   return new Webpoint().WsMethod(param1, param2);
  }
  catch (Exception)
  {
   Thread.Sleep(new TimeSpan(0, 0, sleep_seconds));
  }
 }
}

And Async:

    public static void WsMethodAsync(string param1, int param2, WsMethodCompletedEventHandler handler)
    {
        while (true)
        {
            try
            {
                var server = new Webpoint();
                server.WsMethodAsyncCompleted += delegate(object sender, WsMethodAsyncCompletedEventArgs args)
                {
                    if (args.Error != null)
                    {
                        Thread.Sleep(new TimeSpan(0, 0, sleep_seconds));
                        this.WsMethodAsync(param1, param2, handler);
                    }
                    else
                    {
                        handler(sender, args);
                    }
                };
                server.WsMethodAsyncAsync(param1, param2);
                return;
            }
            catch (Exception)
            {
                Thread.Sleep(new TimeSpan(0, 0, sleep_seconds));
            }
        }
    }

Web服务重新连接模式

我不推荐这种模式。如果调用中的参数有问题,则此调用将永远运行。通常情况下,我会捕获一些预期的异常(CommunicationException, SocketException,无论你需要什么),并为此返回一些状态代码(Ok,或nonnetwork,或其他)。或者将所有预期的异常打包到MyCommunicationException中并抛出this(对调用者隐藏实现细节并使异常处理更容易)

但是把控制权还给调用者,让调用者决定如何继续。不要捕获其他意外异常或重新抛出它们。

调用者可以决定重试一次或三次或其他次数。

如果服务、连接或正在发出的请求确实有问题,那么这将无限期地重复,而不会告诉您哪里出了问题。

服务调用失败意味着什么?它真正失败的频率是多少?最重要的是,为什么原因失败了?如果原因是可以解决的,那就应该解决。没有解决。

作为一个简单的例子,如果这个后端服务调用是由网站的用户发起的(比如,他们试图获取一些数据进行编辑),那么如果调用失败,您只需向用户显示一个错误。比如:

"很抱歉,这个数据现在没有。已通知支持团队此问题。请重试您的请求。如果问题仍然存在,请联系帮助台800-555-1234。"

现在,这不应该只是一个单一的通用错误,无论发生什么都要向用户显示。代码需要足够健壮,能够分辨出不同类型的错误。如果服务不可达,则应用此错误。如果服务说请求无效,那么要么是用户在做什么,要么是你的代码在做什么,这需要修复。等。

如何处理错误并维护可用的应用程序最终取决于您和整个业务。但老实说,我不能推荐你在这个问题上概述的方法。这种方法解决不了任何问题,它只是忽略了问题,直到问题变得更糟。您需要确定错误的根本原因并加以解决,而不是忽略它们。

而且,任何时候错误被抑制/忽略,小猫就会死亡。