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

Основные понятия Windows Communication Foundation

  • Статья

В этом документе представлено общее описание архитектуры Windows Communication Foundation (WCF). В нем приводится объяснение ключевых понятий и их взаимосвязь. Дополнительные сведения по созданию простейшей версии службы и клиента WCF см. в разделе Учебник по началу работы. Информацию по программированию WCF см. в разделе Базовое программирование WCF.

Основы WCF

WCF — это среда выполнения и набор API-интерфейсов для создания систем, которые обеспечивают обмен сообщениями между службами и клиентами. Те же инфраструктура и интерфейсы API используются для создания приложений, обменивающихся данными с другими приложениями на данном компьютере или на компьютере, который находится в другой компании, и доступ к которому можно получить через Интернет.

Обмен сообщениями и конечные точки

В основе WCF лежит принцип связи с помощью обмена сообщениями, и любые объекты, моделируемые в виде сообщений (например, HTTP-запрос или сообщение очереди сообщений, MSMQ), можно представить единым образом в модели программирования. Это обеспечивает универсальный интерфейс API для разных транспортных механизмов.

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

Между конечными точками выполняется обмен сообщениями. Конечные точки — это места, где отправляются или принимаются сообщения и где определяются все сведения, необходимые для обмена сообщениями. Служба предоставляет одну или несколько конечных точек приложения (а также ноль или более конечных точек инфраструктуры), а клиент создает конечную точку, совместимую с одной из конечных точек службы.

Конечная точка стандартным способом описывает место отправки сообщений, способ отправки сообщений и вид сообщений. Служба может предоставлять эту информацию в виде метаданных, которые клиенты могут обрабатывать для создания соответствующих клиентов WCF и стеков связи.

Протоколы связи

Одним из обязательных элементов стека связи является транспортный протокол. Сообщения можно отправлять через интрасети или через Интернет с помощью общих транспортов, таких как HTTP и TCP. Предусмотрены другие транспорты, поддерживающие связь с приложениями очереди сообщений и узлами в сетке одноранговой сети. С помощью встроенных точек расширения WCF можно добавить дополнительные транспортные механизмы.

Другим обязательным элементом в стеке связи является кодирование, определяющее способ форматирования любого заданного сообщения. Служба WCF предоставляет следующие кодировки:

  • кодировка текста — кодирование с возможностью взаимодействия;

  • кодировка подсистемы оптимизации передачи сообщений MTOM — поддерживающий взаимодействие способ эффективной отправки неструктурированных двоичных данных в службу и из нее;

  • двоичное кодирование для эффективной передачи.

Дополнительные механизмы кодирования (например, кодирование сжатием) можно добавить с помощью встроенных точек расширения WCF.

Шаблоны сообщений

Служба WCF поддерживает несколько шаблонов обмена сообщениями, включая запрос-ответ, одностороннюю и дуплексную связь. Разные транспорты поддерживают разные шаблоны обмена сообщениями и таким образом влияют на типы поддерживаемых взаимодействий. Интерфейсы API и среда выполнения WCF также помогают отправлять сообщения безопасно и быстро.

Термины WCF

Ниже перечислены другие понятия и термины, которые используются в документации по WCF.

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

  • конечная точка
    Конструкция, в которой производится отправка или прием сообщений. Она состоит из расположения (адрес), определяющего, куда могут отправляться сообщения, спецификации механизма связи (привязка), описывающей способ отправки сообщений, и определения набора сообщений, которые могут отправляться или приниматься (или и отправляться, и приниматься) в этом расположении (контракт службы), описывающего сообщения, которые могут отправляться.

    Служба WCF видима извне как коллекция конечных точек.

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

  • address
    Задает расположение, где принимаются сообщения. Он задается в виде универсального кода ресурса (URI). Часть URI, определяющая схему, задает транспортный механизм для доставки по адресу, например HTTP и TCP. Иерархическая часть URI содержит уникальное расположение, формат которого зависит от транспортного механизма.

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

    HTTPS://cohowinery:8005/ServiceModelSamples/CalculatorService
  • binding
    Задает способ связи конечной точки с внешним миром. Она состоит из набора компонентов, называемых элементами привязки, которые компонуются в "стек", один над другим, образуя инфраструктуру связи. Как минимум, привязка определяет используемые транспорт (например HTTP или TCP) и кодирование (например, текстовое или двоичное). Привязка может содержать элементы привязки, задающие такие сведения, как механизмы безопасности, используемые для защиты сообщений, или шаблон сообщений, используемый конечной точкой. Дополнительные сведения см. в разделе Настройка служб.
  • элемент привязки
    Представляет определенную часть привязки, такую как транспорт, кодирование, реализация протокола на уровне инфраструктуры (например, WS-ReliableMessaging) или любой другой компонент стека связи.
  • behaviors
    Компонент, управляющий различными аспектами работы службы, конечной точки, определенной операции или клиента во время выполнения. Расширения функциональности группируются в соответствии с областью действия: общие расширения функциональности влияют глобально на все конечные точки, расширения функциональности служб влияют только на аспекты, относящиеся к службам, расширения функциональности конечных точек влияют только на свойства, относящиеся к конечным точкам, а расширения функциональности уровня операции влияют только на конкретные операции. Например, одно расширение функциональности службы регулирующее и определяет реакцию службы при избытке сообщений, превосходящем возможности обработки. С другой стороны, поведение конечной точки управляет только аспектами, относящимися к конечным точкам, например способом поиска учетных данных безопасности и расположением для поиска.
  • привязки, предоставляемые системой
    Служба WCF содержит ряд привязок, предоставляемых системой. Они являются коллекциями элементов привязки, оптимизированными для конкретных сценариев. Например, класс WSHttpBinding предназначен для взаимодействия со службами, реализующими различные спецификации WS-*. Эти заранее определенные привязки экономят время, предоставляя только те параметры, которые могут быть правильно применены для конкретного сценария. Если заранее определенная привязка не удовлетворяет необходимым требованиям, можно создать собственную настраиваемую привязку.
  • конфигурация и кодирование
    Управление приложением возможно с помощью кода, с помощью конфигурации или с помощью и того, и другого. Преимущество конфигурации в том, что параметры клиента или службы могут задаваться пользователями (например, системным администратором), а не только разработчиком, после написания кода и без повторной компиляции. Конфигурация не только позволяет задавать значения, такие как адреса конечных точек, но и обеспечивает дополнительные возможности управления, позволяя добавлять конечные точки, привязки и расширения функциональности. Кодирование позволяет разработчику сохранить полное управление над всеми компонентами службы или клиента; все параметры, заданные при конфигурации, можно проверить и, при необходимости, изменить с помощью кода.
  • операция службы
    Процедура, определенная в программном коде службы и реализующая функциональные возможности операции. Эта операция видима клиентам в виде методов клиента WCF. Метод может возвращать значение и может иметь ряд необязательных аргументов либо может не иметь аргументов и не возвращать никаких значений. Например, операция, выполняющая функцию простого приветствия "Привет", может использоваться для уведомления о наличии клиента и запуска серии операций.
  • контракт службы
    Объединяет несколько связанных операций в один функциональный модуль. Контракт может определять параметры уровня службы, такие как пространство имен службы, соответствующий контракт обратного вызова и другие подобные параметры. В большинстве случаев контракт задается путем создания интерфейса на выбранном языке программирования и применения атрибута ServiceContractAttribute к этому интерфейсу. Фактический код службы создается при реализации этого интерфейса.
  • контракт операции
    Контракт операции определяет параметры операции и тип возвращаемых ею данных. При создании интерфейса, определяющего контракт службы, контракт операции задается применением атрибута OperationContractAttribute к определению каждого метода, входящего в контракт. Операции могут задаваться как получающие одно сообщение и возвращающие одно сообщение или как получающие набор типов и возвращающие тип. В последнем случае формат сообщений, обмен которыми происходит при выполнении данной операции, определяется системой.
  • контракт сообщения
    Описывает формат сообщения. Например, в нем описывается, должны ли элементы сообщения размещаться в заголовках или в тексте, какой уровень безопасности должен применяться к определенным элементам сообщения и т. д.
  • контракт сбоя
    Может связываться с операцией службы для обозначения ошибок, которые могут возвращаться вызывающему объекту. С операцией могут быть связаны ноль или более сбоев. Эти ошибки представляют собой сбои протокола SOAP, которые моделируются в модели программирования как исключения.
  • контракт данных
    Хранящееся в метаданных описание типов данных, используемых службой. Это описание позволяет другим объектам работать со службой. Типы данных могут использоваться в любой части сообщения, например в виде типов параметров или возвращаемых значений. Если в службе используются только простые типы, явное использование контрактов данных не требуется.
  • размещение
    Служба должна быть размещена в некотором процессе. Ведущее приложение — это приложение, контролирующее время существования службы. Службы могут быть резидентными или управляться существующим ведущим процессом.
  • резидентная служба
    Служба, которая выполняется в приложении-процессе, созданном разработчиком. Разработчик контролирует время существования службы, набор свойств службы, открывает службу (при этом служба переходит в режим ожидания данных) и закрывает службу.
  • ведущий процесс
    Приложение, предназначенное для размещения служб. В число таких приложений входят службы IIS, службы активации Windows (WAS) и службы Windows. В этих сценариях основное приложение контролирует время существования службы. Например, с помощью IIS можно создать виртуальный каталог, содержащий сборку службы и файл конфигурации. При получении сообщения IIS запускает службу и контролирует время ее существования.
  • создание экземпляров
    Со службой связана модель создания экземпляров. Существуют три модели создания экземпляров: «один экземпляр», в которой один объект CLR обслуживает всех клиентов, «по вызовам», в которой для обработки каждого вызова, поступившего от клиента, создается новый объект CLR, и «по сеансам», в которой создается набор объектов CLR, по одному на каждый отдельный сеанс. Выбор модели создания экземпляров зависит от требований к приложению и ожидаемого режима использования службы.
  • клиентское приложение
    Программа, обменивающаяся сообщениями с одной или несколькими конечными точками. Клиентское приложение начинает работу с создания экземпляра клиента WCF и вызывает методы этого клиента WCF. Важно отметить, что одно и то же приложение может быть как клиентом, так и службой.
  • канал
    Конкретная реализация элемента привязки. Привязка представляет собой конфигурацию, а канал является реализацией, связанной с этой конфигурацией. Следовательно, с каждым элементом привязки связан канал. Каналы, размещенные друг на другом, образуют конкретную реализацию привязки: стек каналов.

  • клиент WCF
    Конструкция «клиент-приложение», предоставляющая доступ к операциям службы в виде методов (на выбранном языке программирования .NET Framework, например Visual Basic или Visual C#). Каждое приложение может содержать клиент WCF, включая приложение, содержащее службу. Следовательно, можно создать службу, содержащую клиенты WCF других служб.

    Клиент WCF может быть создан автоматически путем использования служебного средства Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe) и нацеливания его на работающую службу, публикующую метаданные.

  • метаданные
    Описывают характеристики службы, которые необходимо знать внешней сущности для обмена данными со службой. Метаданные могут считываться служебным средством Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe) для создания клиента WCF и сопутствующей конфигурации, которые могут использоваться клиентским приложением для взаимодействия со службой.

    Метаданные, предоставляемые службой, содержат документы схемы XML, определяющие контракт данных службы, и документы WSDL, описывающие методы службы.

    Если метаданные для службы включены, они автоматически создаются WCF путем проверки службы и ее конечных точек. Для публикации метаданных службы необходимо явно задать расширение функциональности метаданных.

  • безопасность
    Безопасность в WCF включает обеспечение конфиденциальности (шифрование сообщений для исключения перехвата), целостности (средства обнаружения подделки сообщения), проверку подлинности (средства проверки серверов и клиентов) и авторизацию (управление доступом к ресурсам). Эти функции предоставляются либо путем использования существующих механизмов безопасности, таких как TLS по HTTP (также называемый HTTPS), либо путем реализации одной или нескольких различных спецификаций безопасности WS-*.
  • режим безопасности транспорта
    Указывает, что конфиденциальность, целостность и проверка подлинности обеспечиваются механизмами транспортного уровня (такими как HTTPS). При использовании такого транспорта, как HTTPS, преимущества этого режима заключаются в его эффективной производительности и хорошей известности в связи с преобладающим применением в Интернете. Недостаток заключается в том, что безопасность этого типа применяется отдельно на каждом прыжке пути передачи, в результате чего связь становится чувствительной к атакам типа "злоумышленник в середине".
  • режим безопасности сообщения
    Указывает, что безопасность обеспечивается путем реализации одной или нескольких спецификаций безопасности, таких как спецификация Web Services Security: SOAP Message Security (на английском языке). Каждое сообщение содержит необходимые механизмы, обеспечивающие безопасность во время его передачи и позволяющие получателям обнаруживать подделки, а также расшифровывать сообщения. В этом отношении безопасность заложена внутри каждого сообщения, обеспечивая сквозную безопасность по всем участкам передачи. Поскольку информация безопасности становится частью сообщения, в сообщение можно также включить несколько типов учетных данных (называемых утверждениями). Дополнительным преимуществом такого подхода является возможность безопасной передачи сообщения с помощью любого транспортного механизма, включая несколько транспортных механизмов между источником и назначением. К недостатком этого подхода относится сложность используемых криптографических механизмов, требовательных к производительности.
  • режим безопасности транспорта с учетными данными сообщения
    Задает использование транспортного уровня для обеспечения конфиденциальности, проверки подлинности и целостности сообщений, но каждое сообщение может содержать несколько учетных данных (утверждений), требуемых получателями сообщения.
  • WS-*
    Сокращение для обозначения растущего набора спецификаций веб-служб (WS), таких как WS-Security, WS-ReliableMessaging и т. д., реализованных в WCF.

См. также

Основные понятия

Что такое Windows Communication Foundation
Архитектура Windows Communication Foundation
Архитектура безопасности