Проектирование и реализация служб
В этом разделе показано, как определить и реализовать контракты WCF. Контракт службы указывает, какую информацию конечная точка передает во внешний мир. На более конкретном уровне, это выписка о наборе специальных сообщений, объединенных в такие базовые шаблоны обмена сообщениями (MEP), как запрос/ответ, односторонний обмен и дуплексный обмен. Если контракт службы является логически связанным набором обмена сообщениями, операция службы - это обмен одним сообщением. Например, операция Hello явно должна явно принять одно сообщение (к примеру, вызывающая сторона может объявить приветствие) и может вернуть или не вернуть сообщение (в зависимости от характера операции).
Дополнительные сведения о контрактах и других основных понятиях Windows Communication Foundation (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 автоматически.
Дополнительные сведения о разработке контрактов см. в разделе "Проектирование контрактов службы". Дополнительные сведения о реализации контрактов см. в разделе "Реализация контрактов службы".
На первом плане - сообщения
Использовать управляемые интерфейсы, классы и методы для моделирования операций служб просто, если программист привык к сигнатурам методов стиля удаленного вызова процедур (RPC), когда передача параметров в метод и получение возвращаемых значений является обычной формой запроса функций от объекта или другого типа кода. Например, программисты, использующие управляемые языки, такие как Visual Basic и C++ COM, могут применять свои знания о подходе в стиле RPC (будь то использование объектов или интерфейсов) к созданию контрактов службы WCF без возникновения проблем, связанных с распределенными системами распределенных объектов в стиле RPC. Ориентация службы обеспечивает преимущества слабосвязанного программирования, ориентированного на сообщения, сохраняя при этом удобство и привычность программирования RPC.
Многим программистам удобнее работать с интерфейсами программирования приложений, ориентированными на сообщения, например с очередями сообщений типа MSMQ корпорации Майкрософт, пространствами имен System.Messaging в платформе .NET Framework или с передачей неструктурированных данных XML в запросах HTTP для именования незначительного количества объектов. Дополнительные сведения о программировании на уровне сообщения см. в разделе "Использование контрактов сообщений", программирования на уровне канала обслуживания и взаимодействия с приложениями POX.
Понимание иерархии требований
В контракте службы группируются операции, задаются шаблон обмена сообщениями, типы сообщений и типы данных, передаваемых в этих сообщениях, а также указываются категории поведения во время выполнения, которые должны быть предусмотрены в реализации для поддержки контракта (например, может требоваться, чтобы сообщения шифровались и подписывались). В самом контракте службы точно не указывается, как эти требования удовлетворяются, а указывается только то, что они должны быть удовлетворены. Тип шифрования или способ, с помощью которого подписывается сообщение, соответствует реализации и конфигурации совместимой службы.
Обратите внимание на то, каким способом контракт предъявляет определенные требования к реализации контракта службы и конфигурации среды выполнения для добавления поведения. Набор требований, которые должны быть удовлетворены для передачи службы в использование, основывается на предыдущем наборе требований. Если контракт предъявляет некоторые требования к реализации, реализация может предъявлять дополнительные требования к конфигурации и привязкам, которые позволяют запустить службу. Наконец, ведущее приложение должно также поддерживать любые требования, добавляемые конфигурацией и привязками службы.
Этот процесс аддитивного требования важно учитывать при разработке, реализации, настройке и размещении приложения службы Windows Communication Foundation (WCF). Например, в контракте может указываться, что ему требуется для поддержки сеанса. В этом случае необходимо настроить привязку для поддержки этого требования контракта, иначе реализация службы работать не будет. Если же служба требует встроенной проверки подлинности Windows и размещается в службах IIS, в веб-приложении, где находится служба, должна быть включена встроенная проверка подлинности Windows и отключена поддержка анонимных обращений. Дополнительные сведения о функциях и влиянии различных типов приложений узла службы см. в разделе "Службы размещения".