設計與實作服務Designing and Implementing Services

本節說明如何定義和執行 WCF 合約。This section shows you how to define and implement 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).

如需有關合約和其他核心 Windows Communication Foundation (WCF)概念的詳細資訊,請參閱基本 Windows Communication Foundation 概念For more information about contracts and other core Windows Communication Foundation (WCF) concepts, see Fundamental Windows Communication Foundation Concepts. 本主題將著重於讓您了解服務合約。This topic focuses on understanding service contracts. 如需如何建立使用服務合約連接至服務之用戶端的詳細資訊,請參閱WCF 用戶端總覽For more information about how to build clients that use service contracts to connect to services, see WCF Client Overview.

概觀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 design 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 runtime configuration or the hosting environment may not support.

服務合約Service Contracts

服務合約會指定下列項目:A service contract specifies the following:

  • 合約所公開的作業。The operations a contract exposes.

  • 依據所交換訊息的作業簽章。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:

  1. 採購單合約由 CreateOrderGetOrderStatus 作業組成。That the purchase order contract consisted of CreateOrder and GetOrderStatus operations.

  2. 這些作業擁有指定的輸入訊息和輸出訊息。That the operations have specified input messages and output messages.

  3. 這些訊息可以包含的資料。The data that these messages can carry.

  4. 成功處理訊息時所需要之通訊基礎結構的分類聲明。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.

為了將此類資訊傳遞給許多平臺(包括非 Microsoft 平臺)上的其他應用程式,XML 服務合約會以標準 XML 格式公開表示,例如Web 服務描述語言(WSDL)和XML 架構(XSD),以及其他專案。To convey this kind of information to other applications on many 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, and while WSDL and XSD are excellent languages to describe services in an accessible way, they are difficult languages to use directly and are merely descriptions of a service, not service contract implementations. 因此,WCF 應用程式會使用 managed 屬性、介面和類別來定義服務的結構並加以執行。Therefore, WCF applications use managed attributes, interfaces, and classes both to define the structure of a service and to implement it.

在 managed 類型中定義的產生合約可以在用戶端或其他服務實施者需要時,匯出為中繼資料(WSDL 和 XSD)。The resulting contract defined in managed types can be exported as metadata—WSDL and XSD—when needed by clients or other service implementers. 其結果便是產生一個簡單扼要的程式設計模型,而這個模型可以使用公開中繼資料描述給任何用戶端應用程式。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, the transportation and security-related information, and so on, can be left to WCF, which performs the necessary conversions to and from the service contract type system to the XML type system automatically.

如需設計合約的詳細資訊,請參閱設計服務合約For more information about designing contracts, see Designing Service Contracts. 如需有關如何執行合約的詳細資訊,請參閱執行服務合約For more information about implementing contracts, see Implementing Service Contracts.

最新的訊息Messages Up Front and Center

如果您已經習慣遠端程序呼叫 (RPC) 樣式的方法簽章,那麼使用 Managed 的介面、類別和方法來建立服務作業模型將更為簡單,此時傳遞參數至方法及接收傳回值是物件或其他類型程式碼之要求功能的一般形式。Using managed interfaces, classes, and methods to model service operations is straightforward when you are used to remote procedure call (RPC)-style method signatures, in which passing parameters into a method and receiving return values is the normal form of requesting functionality from an object or other type of code. 例如,使用 managed 語言(例如 Visual Basic 和C++ COM)的程式設計人員可以將 rpc 樣式方法(不論是使用物件或介面)的知識套用至 WCF 服務合約的建立,而不會遇到 rpc 樣式分散式物件系統固有的問題。For example, programmers using managed languages such as Visual Basic and C++ COM can apply their knowledge of the RPC-style approach (whether using objects or interfaces) to the creation of WCF service contracts without experiencing the problems inherent in RPC-style distributed object systems. 服務方向除了提供鬆散耦合、訊息導向之程式設計的優點,同時保留簡易且熟悉的 RPC 程式設計經驗。Service orientation provides the benefits of loosely coupled, message-oriented programming while retaining the ease and familiarity of the RPC programming experience.

有許多程式設計人員更熟悉使用訊息導向的應用程式開發介面,例如 Microsoft MSMQ 之類的訊息佇列、.NET Framework 中的 System.Messaging 命名空間 (Namespace),或在 HTTP 要求中傳送非結構化的 XML,以上只是略舉部分例子。Many programmers are more comfortable with message-oriented application programming interfaces, such as message queues like Microsoft MSMQ, the System.Messaging namespaces in the .NET Framework, or sending unstructured XML in HTTP requests, to name a few. 如需在訊息層級進行程式設計的詳細資訊,請參閱使用訊息合約服務通道層級的程式設計,以及與 POX 應用程式的互通性For more information about programming at the message level, see Using Message Contracts, Service Channel-Level Programming, and Interoperability with POX Applications.

瞭解需求的階層架構Understanding the Hierarchy of Requirements

服務合約可將作業分組、指定訊息交換模式、訊息類型,以及這些訊息所包含的資料型別,並指出實作必須擁有以支援合約的執行階段行為類別 (例如,合約可能會要求加密及簽署訊息)。A service contract groups the operations; specifies the message exchange pattern, 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 does not specify precisely how these requirements are met, only that they must be. 加密類型或簽署訊息的方式取決於實作以及相容性服務的組態。The type of encryption or the manner in which 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. 最後,主應用程式 (Host Application) 也必須支援服務組態和繫結程序所新增的任何需求。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 a 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),則服務所在的 Web 應用程式必須啟用 Windows 整合式驗證並關閉匿名支援。Or if your service requires Windows Integrated Authentication and is hosted in Internet Information Services (IIS), the Web application in which the service resides must have Windows Integrated 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 Services.

請參閱See also