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


Основные понятия 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 предоставляется миру в качестве коллекции конечных точек.

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

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

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

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

HTTPS://cohowinery:8005/ServiceModelSamples/CalculatorService

Привязка
Определяет, как конечная точка взаимодействует с миром. Он создается из набора компонентов, называемых элементами привязки, которые накладываются друг на друга, чтобы создать инфраструктуру коммуникации. По крайней мере, привязка определяет транспорт (например, HTTP или TCP) и используемую кодировку (например, текст или двоичный файл). Привязка может содержать элементы привязки, которые указывают сведения, такие как механизмы безопасности, используемые для защиты сообщений, или шаблон сообщения, используемый конечной точкой. Дополнительные сведения см. в разделе "Настройка служб".

Связывающий элемент
Представляет определенную часть привязки, например транспорт, кодировку, реализацию протокола уровня инфраструктуры (например, WS-ReliableMessaging) или любой другой компонент стека связи.

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

Системные привязки
WCF включает ряд системных привязок. Это коллекции элементов привязки, оптимизированных для определенных сценариев. Например, WSHttpBinding предназначен для интероперабельности со службами, реализующими различные спецификации WS-*. Эти предопределенные привязки экономят время, предоставляя только те параметры, которые можно правильно применить к конкретному сценарию. Если предопределенная привязка не соответствует вашим требованиям, можно создать собственную пользовательскую привязку.

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

Операция службы
Процедура, определенная в коде службы, реализующей функциональные возможности для операции. Эта операция предоставляется клиентам в качестве методов в клиенте WCF. Метод может возвращать значение, принимать необязательное количество аргументов или не принимать аргументов и не возвращать ответ. Например, операция, которая работает как простое "Hello", может использоваться в качестве уведомления о присутствии клиента и начать серию операций.

Контракт службы
Объединяет несколько связанных операций в одну функциональную единицу. Контракт может определять параметры уровня обслуживания, такие как пространство имен службы, соответствующий контракт обратного вызова и другие такие параметры. В большинстве случаев контракт определяется путем создания интерфейса на выбранном языке программирования и применения 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 (Svcutil.exe) и указания на запущенную службу, которая публикует метаданные.

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

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

При включении метаданные службы автоматически создаются WCF, проверяя службу и ее конечные точки. Чтобы опубликовать метаданные из службы, необходимо явно включить поведение метаданных.

Безопасность
В WCF включает конфиденциальность (шифрование сообщений для предотвращения перехвата), целостности (средства для обнаружения изменений в сообщении), проверки подлинности (средства проверки серверов и клиентов) и авторизации (контроль доступа к ресурсам). Эти функции предоставляются либо с помощью существующих механизмов безопасности, таких как TLS через HTTP (также известный как HTTPS), либо путем реализации одной или нескольких различных спецификаций безопасности WS-* .

Режим безопасности транспорта
Указывает, что конфиденциальность, целостность и проверка подлинности предоставляются механизмами транспортного слоя (например, HTTPS). При использовании транспорта, такого как HTTPS, этот режим имеет преимущество за счет высокой производительности и хорошо понимается благодаря своей распространенности в Интернете. Недостатком является то, что этот вид безопасности применяется отдельно к каждому узлу на пути связи, что делает связь уязвимой для атаки типа «человек посередине».

Режим безопасности сообщений
Указывает, что безопасность обеспечивается путем реализации одной или нескольких спецификаций безопасности, таких как спецификация веб-служб Security: SOAP Message Security. Каждое сообщение содержит необходимые механизмы для обеспечения безопасности во время его передачи, а также для того, чтобы получатели могли обнаруживать изменения и расшифровывать сообщения. В этом смысле безопасность встраивается в каждое сообщение, обеспечивая сквозную защиту на каждом этапе. Так как сведения о безопасности становятся частью сообщения, также можно включить несколько типов учетных данных с сообщением (они называются утверждениями). Этот подход также позволяет сообщению безопасно перемещаться по любому транспорту, включая несколько транспортов между его источником и назначением. Недостатком этого подхода является сложность используемых криптографических механизмов, что приводит к последствиям производительности.

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

WS-*
Аббревиатура для растущего набора спецификаций веб-служб (WS), таких как WS-Security, WS-ReliableMessaging и т. д., которые реализованы в WCF.

См. также