КонтрактыContracts

В этом разделе показано, как определить и реализовать контракты службы Windows Communication Foundation (WCF).This section shows you how to define and implement Windows Communication Foundation (WCF)contracts. Контракт службы указывает, какую информацию конечная точка передает во внешний мир.A service contract specifies what an endpoint communicates to the outside world. На более конкретном уровне, это выписка о наборе специальных сообщений, объединенных в такие базовые шаблоны обмена сообщениями (MEP), как запрос/ответ, односторонний обмен и дуплексный обмен.At a more concrete level, it is a statement about a set of specific messages organized into basic message exchange patterns (MEPs), such as request/reply, one-way, and duplex. Если контракт службы является логически связанным набором обмена сообщениями, операция службы - это обмен одним сообщением.If a service contract is a logically related set of message exchanges, a service operation is a single message exchange. Например, операция Hello явно должна явно принять одно сообщение (к примеру, вызывающая сторона может объявить приветствие) и может вернуть или не вернуть сообщение (в зависимости от характера операции).For example, a Hello operation must obviously accept one message (so the caller can announce the greeting) and may or may not return a message (depending upon the courtesy of the operation).

Дополнительные сведения о контрактах и других базовых понятий WCF см. в разделе основные понятия Windows Communication Foundation.For more information about contracts and other core WCF concepts, see Fundamental Windows Communication Foundation Concepts. В данном разделе рассматриваются контракты служб.This topic focuses on understanding service contracts. Дополнительные сведения о том, как создать клиентов, использующих контракты службы для подключения к службам, см. в разделе WCF Client Overview.For more information about how to build clients that use service contracts to connect to services, see WCF Client Overview. Дополнительные сведения о каналах клиента, архитектуре клиента и другие проблемы клиента, см. в разделе клиентов.For more information about client channels, the client architecture, and other client issues, see Clients.

ОбзорOverview

Этот раздел содержит общие концептуальное введение в проектирование и реализация служб WCF.This topic provides a high-level conceptual orientation to designing and implementing WCF services. В подразделах приводятся более подробные сведения об особенностях разработки и реализации.Subtopics provide more detailed information about the specifics of designing and implementation. Перед разработкой и реализацией приложения WCF, рекомендуется, которые:Before designing and implementing your WCF application, it is recommended that you:

  • понять, что представляет собой контракт службы, как он работает и как его создать;Understand what a service contract is, how it works, and how to create one.

  • понять, что контракты устанавливают минимальные требования, которые конфигурация среды выполнения или среда размещения могут не поддерживать.Understand that contracts state minimum requirements that run-time configuration or the hosting environment may not support.

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

Контракт службы - это заявление, в котором принимаются обязательства в отношении:A service contract is a statement that provides information about:

  • группирования операций в службу;The grouping of operations in a service.

  • сигнатуры операций, связанной с обменом сообщениями;The signature of the operations in terms of messages exchanged.

  • типов данных этих сообщений;The data types of these messages.

  • расположения операций;The location of the operations.

  • специальных протоколов и форматов сериализации, используемых для поддержки успешной связи со службой.The specific protocols and serialization formats that are used to support successful communication with the service.

Например, контракт, связанный с заказом на поставку, может содержать операцию CreateOrder, которая принимает входные данные о типах информации заказа и возвращает информацию об успешности или сбое, включая идентификатор заказа.For example, a purchase order contract might have a CreateOrder operation that accepts an input of order information types and returns success or failure information, including an order identifier. Он также может содержать операцию GetOrderStatus, которая принимает идентификатор заказа и возвращает информацию о состоянии заказа.It might also have a GetOrderStatus operation that accepts an order identifier and returns order status information. Контракт службы этого типа указывает:A service contract of this sort would specify:

  • что контракт, связанный с заказом на поставку, состоит из операций CreateOrder и GetOrderStatus;That the purchase order contract consisted of CreateOrder and GetOrderStatus operations.

  • что операции имеют заданные входные и выходные сообщения;That the operations have specified input messages and output messages.

  • данные, которые могут передаваться в этих сообщениях;The data that these messages can carry.

  • категорические заявления об инфраструктуре связи, необходимые для успешной обработки сообщений.Categorical statements about the communication infrastructure necessary to successfully process the messages. Например, эти сведения включают данные о том, требуются ли какие-либо формы безопасности для установления успешной связи, и какие конкретно формы безопасности.For example, these details include whether and what forms of security are required to establish successful communication.

Для передачи такого рода сведения для приложений на других платформах (включая платформы не Майкрософт), контракты XML-служб открыто представляются в стандартных форматах XML, такие как языка описания служб (WSDL) и схемы XML (XSD), среди прочего.To convey this kind of information to applications on other platforms (including non-Microsoft platforms), XML service contracts are publicly expressed in standard XML formats, such as Web Services Description Language (WSDL) and XML Schema (XSD), among others. Разработчики многих платформ могут использовать эти открытые данные контрактов для создания приложений, которые могут взаимодействовать со службой, поскольку они понимают язык спецификации, и эти языки позволяют обеспечить возможность взаимодействия, описывая открытые формы, форматы и протоколы, поддерживаемые службой.Developers for many platforms can use this public contract information to create applications that can communicate with the service, both because they understand the language of the specification and because those languages are designed to enable interoperation by describing the public forms, formats, and protocols that the service supports. Дополнительные сведения о том, как WCF обрабатывает сведения этого типа, см. в разделе метаданных.For more information about how WCF handles this kind of information, see Metadata.

Контракты могут выражаться различными способами. Хотя языки WSDL и XSD отлично подходят для описания служб доступным способом, их трудно использовать непосредственно, и они представляют просто описания службы, а не реализации контракта службы.Contracts can be expressed many ways, however, and while WSDL and XSD are excellent languages to describe services in an accessible way, they are difficult languages to use directly—in any case, they are merely descriptions of a service, not service contract implementations. Таким образом приложения WCF использовать управляемые атрибуты, интерфейсы и классы для определения структуры и реализации службы.Therefore, WCF applications use managed attributes, interfaces, and classes both to define the structure of and to implement a service.

Получающийся контракт, определенный в управляемых типах может быть преобразован (также называется экспортировать) как метаданные — WSDL и XSD, когда требуется клиентам или другим ответственным за реализацию службы, особенно на других платформах.The resulting contract defined in managed types can be converted (also called exported) as metadata—WSDL and XSD—when needed by clients or other service implementers, especially on other platforms. Результат — простая модель программирования, которая может быть описана с использованием открытых метаданных для любого клиентского приложения.The result is a straightforward programming model that can be described using public metadata to any client application. Сведения о базовых сообщений SOAP, например о транспорте и сведения, относящиеся к безопасности, можно оставить в WCF, который автоматически выполняет необходимые преобразования в и из системы типа контракта службы в систему типов XML.The details of the underlying SOAP messages, such as the transportation and security-related information, can be left to WCF, which automatically performs the necessary conversions to and from the service contract type system to the XML type system.

Дополнительные сведения о разработке контрактов см. в разделе Designing Service Contracts.For more information about designing contracts, see Designing Service Contracts. Дополнительные сведения о реализации контрактов см. в разделе Implementing Service Contracts.For more information about implementing contracts, see Implementing Service Contracts.

Кроме того WCF предоставляет также возможность разрабатывать контракты службы целиком на уровне сообщений.In addition, WCF also provides the ability to develop service contracts entirely at the message level. Дополнительные сведения о разработке контрактов службы на уровне сообщений, см. в разделе Using Message Contracts.For more information about developing service contracts at the message level, see Using Message Contracts. Дополнительные сведения о разработке служб SOAP XML см. в разделе взаимодействие с приложениями POX.For more information about developing services in non-SOAP XML, see Interoperability with POX Applications.

Понимание иерархии требованийUnderstanding the Hierarchy of Requirements

В контракте службы группируются операции, задаются шаблон обмена сообщениями, типы сообщений и типы данных, передаваемых в этих сообщениях, а также указываются категории поведения во время выполнения, которые должны быть предусмотрены в реализации для поддержки контракта (например, может требоваться, чтобы сообщения шифровались и подписывались).A service contract groups the operations; specifies the MEP, message types, and data types those messages carry; and indicates categories of run-time behavior an implementation must have to support the contract (for example, it may require that messages be encrypted and signed). В самом контракте службы, однако, точно не указывается, как удовлетворяются эти требования, а указывается только то, что они должны быть удовлетворены.The service contract itself, however, does not specify precisely how these requirements are met, only that they must be. Выбор типа шифрования или способа, с помощью которого подписывается сообщение, определяются реализацией и конфигурацией совместимой службы.What type of encryption or how a message is signed is up to the implementation and configuration of a compliant service.

Обратите внимание на то, каким способом контракт предъявляет определенные требования к реализации контракта службы и конфигурации среды выполнения для добавления поведения.Notice the way that the contract requires certain things of the service contract implementation and the run-time configuration to add behavior. Набор требований, которые должны быть удовлетворены для передачи службы в использование, основывается на предыдущем наборе требований.The set of requirements that must be met to expose a service for use builds on the preceding set of requirements. Если контракт предъявляет некоторые требования к реализации, реализация может предъявлять дополнительные требования к конфигурации и привязкам, которые позволяют запустить службу.If a contract makes requirements of the implementation, an implementation can require yet more of the configuration and bindings that enable the service to run. Наконец, ведущее приложение должно также поддерживать любые требования, добавляемые конфигурацией и привязками службы.Finally, the host application must also support any requirements that the service configuration and bindings add.

Этот аддитивный процесс предъявления требований важно помнить при проектировании, реализации, настройке и размещении приложения службы Windows Communication Foundation (WCF).This additive requirement process is important to keep in mind while designing, implementing, configuring, and hosting your Windows Communication Foundation (WCF) service application. Например, в контракте может указываться, что ему требуется для поддержки сеанса.For example, the contract can specify that it needs to support a session. В этом случае необходимо настроить привязку для поддержки этого требования контракта, иначе реализация службы работать не будет.If so, then you must configure the binding to support that contractual requirement, or the service implementation will not work. Если же служба требует встроенной проверки подлинности Windows и размещается в службах IIS, в веб-приложении, где находится служба, то должна быть включена встроенная проверка подлинности Windows и отключена поддержка анонимных обращений.Or if your service requires Integrated Windows authentication and is hosted in Internet Information Services (IIS), the Web application in which the service resides must have Integrated Windows authentication turned on and anonymous support turned off. Дополнительные сведения о функциях и влиянии различных типов ведущих служб приложения, см. в разделе размещения.For more information about the features and impact of the different service host application types, see Hosting.

См. такжеSee also