Контракты
В этом разделе показано, как определить и реализовать контракты 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 и отключена поддержка анонимных обращений. Дополнительные сведения о функциях и влиянии различных типов приложений узла службы см. в разделе "Размещение".