2.1.2 Windows Communication Foundation (WCF)
Windows Communication Foundation (WCF) is the .NET Framework technology that is used to create independently versionable, secure, and reliable service-oriented applications. Applications that use WCF can communicate by using message schemas and choreographies defined in the WS-* specifications. WCF complies with many WS-* specifications.
Following is a brief overview describing the most relevant WCF features and how they relate to the various protocols that are mentioned in this document.
WCF supports many different security models and makes it easy to implement widely accepted security measures. Because WCF has an extensible architecture, it is also relatively easy to extend WCF security to meet the requirements of a particular application. The default security options range from the traditional transport-centric security to more modern message-based security, as specified in WS-Security [WSS] and related specifications.
Distributed applications may require reliable messaging. For this purpose, WCF implements WS-ReliableMessaging and extensions to WS standards including the Advanced Flow Control Extension ([MS-WSRVCRM]) and Reliable Request-Reply Extension ([MS-WSRVCRR]).
WCF allows transactional scopes to flow across multiple applications. WCF implements WS-AtomicTransaction and its extension ([MS-WSRVCAT]), enabling software entities that use the WS-AtomicTransaction protocol to participate in transactions that are coordinated by OleTx transaction managers, as specified in [MS-DTCO]. The entire set of transaction-related protocols supported in Windows, including [MS-WSRVCAT], is described in [MS-TPSO].
Applications, which are built on WCF, can communicate with other applications that can use WS-*, Basic Profile (BP), and XML messages over TCP, HTTP, named pipes, and Microsoft Message Queuing (MSMQ).
Bindings: Specifies all bindings that can be used by any endpoint that is defined in any service. The binding elements that are contained in the bindings element can be either one of the system-provided bindings or a custom binding. A binding defines which type of transport, security, and encoding is used, and whether reliable sessions, transactions, or streaming is supported or enabled.
Services: Contains the specifications for all services that the application hosts. Each service specification contains an endpoint element that provides the following information:
Address: Specifies the service's Uniform Resource Identifier (URI), which can be an absolute address or one that is given relative to the base address of the service.
Binding: Specifies a system-provided or user-defined binding.
Contract: Specifies the interface that defines the contract.
Behaviors: Contains a collection of settings for the behavior of a service-like discoverability of service endpoints, settings that authorize access to service operations, the timeout for a service, throttling mechanism of a WCF service, and so on.
The protocol stack in WCF can be configured by the developer in code, or by the developer or end user by simply changing configuration entries in the application's XML configuration file. Although an understanding of the WCF application configuration schema is not necessary to interoperate with WCF-based applications at the protocol level, certain elements of that schema are discussed in this overview document in order to provide an understanding of how those configuration elements can influence the network communications of a WCF-based application. The recommended order of stack elements is the following:
Reliable messaging (optional)
The following diagram represents the protocol stack of WCF.
Figure 3: The protocol stack of Windows Communication Foundation
The various components in the preceding diagram are described in the following paragraphs.
A transport is a means of communicating with a source on the service side. The transport channel is the bottom-most channel of the WCF stack. The protocols that are typically used in this channel are HTTP, TCP, MSMQ, and named pipes, but WCF allows application developers to use other transports as well, such as Simple Mail Transfer Protocol (SMTP) or File Transfer Protocol (FTP).
The SOAP encoding defines a set of rules for mapping programmatic types to XML. XML allows very flexible encoding of data, whereas SOAP defines a narrower set of rules for encoding the graphs in the SOAP Data Model specified in [SOAP1.1] section 2.
[MC-NBFX], [MC-NBFS], and [MC-NBFSE]
[MC-NBFX] defines the .NET Binary Format: XML Data Structure, which is a binary format that can represent many XML documents. [MC-NBFS] extends [MC-NBFX] for the SOAP data structure and specifies a way to efficiently encode strings that are common to many SOAP messages. [MC-NBFSE] extends [MC-NBFS], and defines a mechanism by which strings may be transmitted once and referred to by subsequent XML documents.
.NET Message Framing ([MC-NMF])
Figure 4: [MC-NMF] and related protocols
Message framing is the breaking up of a stream of data into demarcated units that are called messages. Some protocols such as HTTP natively include a notion of message framing. Other protocols such as TCP do not natively include a notion of message framing and therefore must rely on a protocol that does provide message framing. WCF includes a message framing protocol that is called .NET Message Framing for use with transports that do not natively support messaging. This framing protocol is used with the TCP transport to create NetTcp and with the MSMQ transport to create NetMsmq.
The .NET Message Framing Protocol [MC-NMF], can use any of the following encoding specifications: UTF-8, UTF-16, Little Endian Unicode, and MTOM, as specified in [SOAP-MTOM], [MC-NBFS], and [MC-NBFSE].
The .NET Message Framing TCP Binding Protocol [MS-NMFTB] and the .NET Message Framing MSMQ Binding Protocol [MS-NMFMB] specify how the mechanism, described in [MC-NMF], for framing messages over any transport protocol can be applied over TCP and Message Queue (MSMQ) respectively.
Reliable Messaging and Flow Control
WCF implements WS-ReliableMessaging to allow messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. It implements the WS-ReliableMessaging Protocol: Advanced Flow Control Extension [MS-WSRVCRM], which extends WS-ReliableMessaging and provides an advanced message flow control. This protocol attempts to minimize the number of dropped messages by synchronizing the rate at which the reliable messaging source (RMS) sends messages with the rate at which the reliable messaging destination (RMD) can receive them.
Reliable Request Reply
The WS-ReliableMessaging Protocol: Reliable Request-Reply Extension ([MS-WSRVCRR]) extends WS-ReliableMessaging by enabling applications to communicate reliably over transfer protocols that only support the SOAP Request-Response protocol.
Windows implements WS-* protocols that are designed for secure communication. These protocols include WS-Security, WS-SecurityPolicy, WS-Trust, and WS-SecureConversation.
Web Services: The Security Policy Assertions Format ([MS-WSSEC]) defines additional policy assertions that can be used together with policy assertions that are defined in WS-Security Policy ([WSSP]) to express constraints and requirements that cannot be expressed with the policy assertions that are defined in [WSSP] alone.
Figure 5: Security and Policy extensions
WS-Policy defines a framework for allowing Web services to express their constraints and requirements. Such constraints and requirements are expressed as policy assertions. WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies.
Web services: Policy Assertions and WSDL Extensions ([MS-WSPOL]) specifies a collection of Web service policy assertions and Web Services Description Language (WSDL) extensions that define domain-specific behavior for the interaction between two Web service entities.
The .NET Packet Routing Protocol [MC-NPR] defines a SOAP header for indicating that a SOAP message can safely be treated as a packet or datagram. The .NET Packet Routing Protocol does not prescribe any specific algorithm or communications infrastructure for forwarding a packet after it has been received by the router. The .NET Packet Routing Protocol enables a SOAP message originator to indicate that a message does not have a behavioral dependency on the path that is taken to deliver the message from the source to the destination. A .NET Packet Routing Protocol router may use this indication when selecting among different routing algorithms to apply to the message. The indication provided by the .NET Packet Routing Protocol conveys routing information that may enable the router to select a more efficient routing algorithm.
The .NET Tracing Protocol [MS-NETTR] defines a SOAP message header for correlating sets of messages. Diagnosing errors in distributed applications is a complex task that usually involves multiple messages. By correlating messages between distributed application endpoints, users can map message exchanges and infer causality relationships between messages. This information helps isolate the set of messages that led up to an error and the set of messages that resulted from it.
The .NET Tracing Protocol provides two main functions:
It enables users to map outgoing messages to incoming messages between components in a distributed application. It does this by assigning each message a unique identifier, named the CorrelationId.
It provides a way to group related messages together.
The .NET Context Exchange Protocol [MC-NETCEX] specifies a message syntax for identifying context that is shared between a client and a server that is independent of connection usage, and a protocol for establishing that context. This protocol specifies two roles for context exchange: a client role and a server role. The server role is responsible for creating context identifiers in response to client requests and associating context identifiers with resources. The protocol also specifies two roles for callback context exchange: a client role and a server role.
Figure 6: Relationship of Peer Channel Protocol to other protocols
The Peer Channel Protocol ([MC-PRCH]) is used for broadcasting messages over a virtual network of cooperating nodes, and to send and receive messages between nodes in a named mesh. The nodes form the network by establishing connections to each other by using a discovery service in which every node registers itself into a named mesh and discovers other nodes that are using the name of the mesh.
PRCH optionally uses PRCR ([MC-PRCR]) to register and resolve peers' addresses during connection and maintenance operations.
Discovery and Addressing
Figure 7: Discovery and Addressing Stack
The various components of the preceding diagram are described in the following paragraphs.
WCF implements WS-Discovery and an extension, WSTC ([MS-WSTC]), which allows discovery of services in ad hoc networks with a minimum of networking services (for example, where there are no DNS or directory services). The WS-Discovery: Termination Criteria Protocol Extensions ([MS-WSTC]) is an extension of the WS-Discovery Protocol ([WS-Discovery]) for sending and receiving termination criteria as part of the WS-Discovery Probe and Resolve messages. WS-Discovery can be used without its extension [MS-WSTC].
PRCR, the Peer Channel Custom Resolver Protocol ([MC-PRCR]) is a client/server protocol that is used to register and retrieve client endpoint information at a well-known resolver service. The information that is registered and retrieved is the PeerNodeAddress of clients that are associated with a named mesh. This information can then be used to establish direct connections among these clients. This protocol is transport-agnostic, and therefore may be used together with a variety of transport protocols such as TCP and HTTP. It is intended for use by PRCH, the Peer Channel Protocol ([MC-PRCH]) for neighbor discovery when PNPR, the Peer Name Resolution Protocol ([MS-PNRP]) is unavailable.
WCF implements WS-Addressing, which is one of the WS-* specifications that provides a framework for one of the most fundamental tasks of any service-oriented application, namely indicating the target of a message.