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