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

Контракты

  • Статья

В настоящем разделе описывается, как определить и реализовать контракты Windows Communication Foundation (WCF). Контракт службы указывает, какую информацию конечная точка передает во внешний мир. На более конкретном уровне, это выписка о наборе специальных сообщений, объединенных в такие базовые шаблоны обмена сообщениями (MEP), как запрос/ответ, односторонний обмен и дуплексный обмен. Если контракт службы является логически связанным набором обмена сообщениями, операция службы — это обмен одним сообщением. Например, операция Hello явно должна явно принять одно сообщение (к примеру, вызывающая сторона может объявить приветствие) и может вернуть или не вернуть сообщение (в зависимости от характера операции).

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

Общие сведения

В настоящем разделе дается высокоуровневое введение в принципы разработки и реализации служб WCF. В подразделах приводятся более подробные сведения об особенностях разработки и реализации. Перед разработкой и реализацией приложения WCF рекомендуется:

  • понять, что представляет собой контракт службы, как он работает и как его создать;

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

Контракты служб

Контракт службы — это заявление, в котором принимаются обязательства в отношении:

  • группирования операций в службу;

  • сигнатура операций в терминах обмена сообщениями;

  • типов данных этих сообщений;

  • расположения операций;

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

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

  • что контракт, связанный с заказом на поставку, состоит из операций CreateOrder и GetOrderStatus;

  • что операции имеют заданные входные и выходные сообщения;

  • данные, которые могут передаваться в этих сообщениях;

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

Чтобы передать сведения этого типа в другие приложения на других платформах (включая платформы не Майкрософт), контракты XML-служб открыто представляются в стандартных форматах XML, например в формате языка описания веб-служб (WSDL), в формате схемы XML (XSD) и других форматах. Разработчики многих платформ могут использовать эту открытую информацию контрактов для создания приложений, которые могут связываться со службой, поскольку эти приложения понимают язык спецификации и эти языки позволяют обеспечить взаимодействие, описывая открытые формы, форматы и протоколы, поддерживаемые службой. Дополнительные сведения том, как WCF обрабатывает данный тип информации, см. Метаданные.

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

Получающийся контракт, определенный в управляемых типах, может быть преобразован (или экспортирован) как метаданные (WSDL и XSD), когда это требуется клиентам или другим ответственным за реализацию службы, особенно на других платформах. Результат — простая модель программирования, которая может быть описана с использованием открытых метаданных для любого клиентского приложения. Подробности базовых сообщений SOAP, такие как информация о транспорте и безопасности, могут быть предоставлены WCF, который автоматически выполняет необходимые преобразования в систему типа контракта службы и из системы типа контракта службы в систему типа XML.

Дополнительные сведения разработке контрактов см. в разделе Создание контрактов служб. Дополнительные сведения реализации контрактов, см. в разделе Реализация контрактов служб.

Кроме того, WCF также дает возможность разрабатывать контракты службы целиком на уровне сообщения. Дополнительные сведения разработке контрактов службы на уровне сообщения см. Использование контрактов сообщений. Дополнительные сведения разработке служб в XML-коде, не относящемся к протоколу SOAP, см. в разделе Взаимодействие с приложениями POX.

Понимание иерархии требований

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

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

Этот аддитивный процесс предъявления требований важно иметь в виду при разработке, реализации, настройке и размещении приложения службы Windows Communication Foundation (WCF). Например, в контракте может указываться, что ему требуется для поддержки сеанса. В этом случае необходимо настроить привязку для поддержки этого требования контракта, иначе реализация службы работать не будет. Если же служба требует встроенной проверки подлинности Windows и размещается в службах IIS, в веб-приложении, где находится служба, должна быть включена встроенная проверка подлинности Windows и отключена поддержка анонимных обращений. Дополнительные сведения функциях и влиянии различных типов ведущих приложений служб см. Размещение.

См. также

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

Конечные точки: адреса, привязки и контракты
Создание контрактов служб
Реализация контрактов служб