Поделиться через

Middle-Tier клиентские приложения

В этом разделе рассматриваются различные проблемы, связанные с клиентскими приложениями среднего уровня, используюющими Windows Communication Foundation (WCF).

Повышение производительности клиента Middle-Tier

По сравнению с предыдущими технологиями коммуникации, такими как веб-службы с помощью ASP.NET, создание экземпляра клиента WCF может быть более сложным из-за расширенного набора функций WCF. Например, когда объект ChannelFactory<TChannel> открыт, он может установить безопасный сеанс со службой, что увеличивает время запуска экземпляра клиента. Как правило, эти дополнительные возможности функций не влияют на клиентские приложения, так как клиент WCF выполняет несколько вызовов, а затем закрывается.

Однако клиентские приложения среднего уровня могут быстро создавать множество клиентских объектов WCF и, в результате, повысить требования к инициализации. Существует два основных подхода к повышению производительности приложений среднего уровня при вызове служб:

  • Кэшируйте клиентский объект WCF и повторно используйте его для последующих вызовов, где это возможно.

  • ChannelFactory<TChannel> Создайте объект, а затем используйте этот объект для создания новых объектов клиентского канала WCF для каждого вызова.

Ниже приведены проблемы, которые следует учитывать при использовании этих подходов:

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

  • Если служба должна выполнять проверку подлинности на основе каждого клиента, необходимо создать новый клиент для каждого входящего запроса на среднем уровне вместо повторного использования клиента WCF (или объекта клиентского канала WCF), так как учетные данные клиента среднего уровня нельзя изменить после создания клиента WCF (или ChannelFactory<TChannel>).

  • Хотя каналы и клиенты, созданные каналами, являются потокобезопасными, возможно, они не поддерживают одновременную отправку нескольких сообщений по каналу связи. Если вы отправляете большие сообщения, особенно при потоковой передаче, операция отправки может заблокироваться в ожидании завершения другой отправки. Это приводит к двум типам проблем: отсутствие параллелизма и возможность взаимоблокировки, если поток управления возвращается в службу, повторно использующую канал (то есть совместно используемый клиент вызывает службу, исполнение кода которой приводит к обратному вызову клиента). Это верно независимо от типа используемого клиента WCF.

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

Пример, демонстрирующий рекомендации по повторному использованию клиента для нескольких запросов, см. в разделе "Привязка данных" в клиенте ASP.NET.

Кроме того, можно повысить производительность запуска для тех клиентов, которые используют сериализуемые типы данных, с помощью генерации и компиляции кода сериализации для этих типов данных во время выполнения, так как это может вызвать замедление производительности запуска. Средство служебной программы метаданных ServiceModel (Svcutil.exe) может повысить производительность запуска для этих приложений, создав необходимый код сериализации из скомпилированных сборок для приложения. Дополнительные сведения см. в разделе "Практическое руководство. Улучшение времени запуска клиентских приложений WCF с помощью xmlSerializer".

См. также