Шаблон повторного подключения веб-службы - PullRequest
Новая
       1

Шаблон повторного подключения веб-службы

0 голосов
/ 14 сентября 2011

Я занимаюсь разработкой приложения .Net Webform с интенсивным использованием веб-служб для связи с базой данных внешнего сервера.

Итак, я пытаюсь найти лучший способ справиться с отключениями и сбоями при вызове метода WS.

На данный момент я создал прокси-функцию - своего рода уровня - для каждого вызываемого мной метода WS, который повторяет определенный вызов WS в цикле до тех пор, пока он не завершится успешно.

Для вызовов Sync и Async я решил свою проблему, но я добавил раздражающий дополнительный слой к своему уровню WebService, с дополнительным обслуживанием и большим количеством избыточного кода.

Я отказываюсь верить, что для этой стандартной ситуации не существует решения, но нигде не могу его найти.

Есть идеи?

Ниже приведен пример моего дополнительного слоя (Sync): 

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));
  }
 }
}

и 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));
            }
        }
    }

Ответы [ 2 ]

1 голос
/ 14 сентября 2011

Если бы что-то было действительно не так с сервисом, или с подключением к нему, или с выполнением запроса, то это повторялось бы бесконечно, даже не сообщая вам, что не так.

Каковы последствия сбоя вызова службы? Как часто это действительно терпит неудачу? И, самое главное, по какой причине он терпит неудачу? Если причина является чем-то, что может быть исправлено, это должно быть исправлено. Не работал вокруг.

В качестве простого примера, если этот внутренний сервисный вызов инициирован пользователем веб-сайта (скажем, они пытаются получить некоторые данные для редактирования), то, если вызов не удался, вы просто сообщаете об ошибке пользователь. Что-то вроде:

"Извините, но в настоящее время эти данные недоступны. Служба поддержки была уведомлена об этой проблеме. Пожалуйста, повторите запрос. Если проблема не устранена, обратитесь в службу поддержки по телефону 800-555-1234. . "

Теперь, это не должна быть просто общая ошибка, чтобы показать пользователю, что бы ни случилось. Код должен быть достаточно надежным, чтобы отличать один тип ошибки от другого. Если служба недоступна, эта ошибка применяется. Если служба сообщает, что запрос недействителен, значит, что-то не так с пользователем или с вашим кодом, и это нужно исправить. Etc.

То, как вы справляетесь с ошибками и поддерживаете работоспособное приложение, в конечном итоге зависит от вас и бизнеса в целом. Но я, честно говоря, не могу рекомендовать подход, который вы изложите в вопросе. Такой подход ничего не решает, он просто игнорирует проблему, пока не станет хуже. Вам необходимо определить причину ошибок и устранить их, а не игнорировать их.

Кроме того, каждый раз, когда ошибка подавляется / игнорируется, котенок умирает.

1 голос
/ 14 сентября 2011

Я бы не рекомендовал этот шаблон. Если есть какие-то проблемы с параметрами вашего вызова, это будет продолжаться вечно. Обычно я ловил бы несколько ожидаемых исключений (CommunicationException, SocketException, все, что вам нужно) и возвращал для этого некоторый код состояния (Ok, NoNetwork или любой другой). Или оберните все ожидаемые исключения в MyCommunicationException и сгенерируйте это (чтобы скрыть детали реализации от вызывающего и упростить для него обработку исключений)

Но верните управление вызывающему абоненту и позвольте вызывающему решить, как поступить. Не ловите другие неожиданные исключения и не перебрасывайте их.

После этого вызывающий абонент может решить попробовать снова и снова, либо 3 раза или еще что-нибудь.

...