Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе показано, как определить и реализовать контракты Windows Communication Foundation (WCF). Контракт службы указывает, что конечная точка взаимодействует с внешним миром. На более конкретном уровне это заявление о наборе определенных сообщений, организованных в базовые шаблоны обмена сообщениями (MEPs), такие как запрос или ответ, односторонний и дуплексный. Если контракт на обслуживание представляет собой логически взаимосвязанный набор обменов сообщениями, то операция сервиса — это единичный обмен сообщениями. Например, операция должна, очевидно, 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".
Общие сведения о иерархии требований
Контракт службы группирует операции; указывает MEP, типы сообщений и типы данных, которые несут эти сообщения; и указывает категории поведения среды выполнения, которые реализация должна поддерживать, чтобы соответствовать контракту (например, может потребоваться, чтобы сообщения были зашифрованы и подписаны). Однако сам контракт службы не указывает точно, как выполняются эти требования, только то, что они должны быть. Тип шифрования или способ подписания сообщения зависит от реализации и настройки соответствующей службы.
Обратите внимание, что контракт требует определенные требования к реализации контракта службы и конфигурации среды выполнения, чтобы добавить поведение. Набор требований, которые должны быть выполнены для предоставления службы для использования на основе предыдущего набора требований. Если контракт предъявляет требования к реализации, реализация может требовать еще больше конфигурации и привязок, необходимых для функционирования службы. Наконец, ведущее приложение также должно поддерживать все требования, которые добавляются в конфигурацию и привязки службы.
Этот процесс аддитивного требования важно учитывать при разработке, реализации, настройке и размещении приложения службы Windows Communication Foundation (WCF). Например, контракт может указать, что он должен поддерживать сеанс. Если это так, необходимо настроить привязку для поддержки этого договорного требования, или реализация службы не будет работать. Или, если ваша служба требует встроенной проверки подлинности Windows и размещена в Интернет-службах (IIS), веб-приложение, в котором размещена эта служба, должно иметь включенную встроенную проверку подлинности Windows и отключенную анонимную поддержку. Дополнительные сведения о функциях и влиянии различных типов приложений узла службы см. в разделе "Размещение".