Проектирование и реализация служб

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

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

Обзор

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

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

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

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

В контракте службы определено следующее:

  • операции, предоставляемые контрактом;

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

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

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

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

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

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

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

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

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

Чтобы передать данные такого рода другим приложениям на многих платформах (включая платформы сторонних производителей), контракты служб 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 для именования незначительного количества объектов. Дополнительные сведения о программировании на уровне сообщений см. в статьях использование контрактов сообщений, Программирование служб Channel-Levelи взаимодействие с приложениями POX.

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

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

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

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

См. также