다음을 통해 공유

Choosing a Transport

  • 아티클

This article is now a part of the Windows SDK.

This is the last planned article in a documentation series covering various aspects of Windows Communication Foundation transports. Today's topic covers how to choose a transport and associated encoder.

Choosing a Transport

The Windows Communication Foundation (WCF) programming model separates the behavior of endpoint operations from the transport mechanism that connects two endpoints.  This gives you flexibility when deciding how your services should be exposed to the network.  Transports and message encoders are pieces of WCF that sit below a service to provide connectivity.  This document discusses some of the characteristics you need to evaluate when choosing a transport and message encoding.

In scenarios where you must connect to a preexisting client or server, you may not have a choice about using a particular transport and message encoding.  However, WCF services can be made accessible through multiple endpoints, each with a different transport or message encoding.  When a single selection does not cover the entire intended audience for your service, you should consider exposing your service over multiple endpoints.  Client applications can then choose the endpoint that is most favorable for them.  Using multiple endpoints allows you to combine the advantages of different transports and message encoders.

Transports and Message Encoders

In WCF, the transfer of data across a network requires the joint cooperation of a transport and message encoder.

A message encoder converts a System.ServiceModel.Channels.Message to a serialized form.  This document covers the Text, Binary, and MTOM message encoders that are included in WCF.  The text message encoder supports both a plain XML encoding as well as SOAP encodings.  The plain XML encoding mode of the text message encoder is called the POX encoder to distinguish it from the text-based SOAP encoding.

A transport sends the serialized form of the message to another application.  This document covers the HTTP, TCP, and named pipe transports that are included in WCF.  WCF provides several standard bindings that combine a transport, message encoder, and other options.  For instance, the BasicHttpBinding binding combines the HTTP transport with a text message encoder.  Similarly, the NetTcpBinding binding combines the TCP transports with a binary message encoder.  You are not limited to choosing a preset combination given by a standard binding.

Decision Points for Choosing a Transport

The following table describes several decision points commonly used when choosing a transport. You should add new attributes and transports to this list as you identify them. The general process you should use is to identify the attributes that are important for your application, identify the transports that associate favorably with each of your chosen attributes, and then select the transports that work best with your attribute set.

Attribute

Description

Favored Transports

Connectivity

The connectivity of a transport reflects how capable the transport is at reaching other systems.  The named pipe transport has very little reach; it can only connect to services running on the same machine.  The TCP and HTTP transports both have excellent reach and can penetrate some NAT and firewall configurations.  See the Working with NATs and Firewalls document for more details.

HTTP, TCP

Diagnostics

Diagnostics allow you to automatically detect connectivity problems with a transport.  The named pipe transport generally has easier to diagnose errors because both endpoints of the connection must be on the same machine.  All transports support the ability to send back fault information that describes connectivity.  However, WCF does not come with diagnostic tools for investigating network issues.

Hosting

All WCF endpoints need to be hosted inside of some application.  IIS 6.0 and earlier only support hosting applications that use the HTTP transport.  On Windows Vista, support is added for hosting all WCF transports, including the TCP and named pipe transports.  See the documentation for Hosting in IIS and Hosting in WAS for more details.

HTTP

Inspection

Inspection is the ability to examine messages during transmission.  The HTTP protocol separates routing and control information from data, making it easier to build tools that inspect and analyze messages.  The level of security used will impact whether messages can be inspected.

HTTP

Latency

Latency is the minimum amount of time required to complete an exchange of messages.  All network operations have some latency, although this amount can be increased by the choice of transport.  Using duplex or one-way communication with a transport whose native message exchange pattern is request-reply, such as HTTP, can cause additional latency due to the forced correlation of messages.  In this situation, consider using a transport whose native message exchange pattern is duplex, such as TCP.

TCP, named pipe

Security

Security is the capability of protecting messages during transfer, either by supplying confidentiality, integrity, or authentication.  Confidentiality protects a message from being examined, integrity protects a message from being modified, and authentication gives assurances about the sender or receiver of the message.  WCF supports transfer security both at the message level and transport level.  Message security will compose with any transport as long as the transport supports a buffered transfer mode.  The support for transport security will vary depending on the chosen transport.  The HTTP, TCP, and named pipe transports have reasonable parity in their support for transport security.

All

Throughput

Throughput measures the amount of data that can be transmitted and processed in a specified period of time.  Like latency, the throughput for service operations can be affected by the chosen transport.  Maximizing throughput for a transport requires minimizing both the overhead of transmitting content as well as minimizing the time spent waiting for message exchanges to complete.  Both the TCP and named pipe transports add little overhead to the message body and support a native duplex shape that reduces the need to wait for message replies.

TCP, named pipe

Tooling

Tooling represents the support for a protocol by third-party applications for development, diagnosis, hosting, and other activities.  There has been a particularly large investment in providing tools and software for working with the HTTP protocol.

HTTP

Decision Points for Choosing a Message Encoder

The following table describes several decision points commonly used when choosing a message encoder. You should add new attributes and message encoders to this list as you identify them. The general process you should use is to identify the attributes that are important for your application, identify the message encoders that associate favorably with each of your chosen attributes, and then select the message encoders that work best with your attribute set.

Attribute

Description

Favored Encodings

Inspection

Inspection is the ability to examine messages during transmission.  Text encodings, either with or without the use of SOAP, allow messages to be inspected and analyzed by many applications without the use of specialized tools.  Note that the use of transfer security, at either the message or transport level, will impact your ability to inspect messages.  Confidentiality protects a message from being examined and integrity protects a message from being modified.

Text, POX

Reliability

Reliability is the resiliency that an encoding has to errors in transmission.  Reliability can also be provided at the message, transport, or application level.  All of the standard WCF encodings assume that reliability is being provided at some other layer.  There is generally little ability for the encoding to recover from an error in transmission.

Simplicity

Simplicity represents with which encoders and decoders can be created for an encoding specification.  Text encodings are particularly advantageous for simplicity, and the POX encoder has the additional advantage of not requiring support for processing SOAP.

POX

Size

The encoding size is the amount of overhead imposed on content by the message encoding.  The size of encoded messages is directly related to the maximum throughput of service operations.  Binary encodings are generally more compact than text encodings.  When message size is at a particular premium, you may consider additionally compressing the message contents during encoding.  However, compression adds additional processing costs for both the message sender and receiver.

Binary

Streaming

Streaming allow applications to begin processing a message before the entire message has arrived.  Effectively using streaming requires that the important data for a message be available at the beginning of the message so that the receiving application does not need to wait for it to arrive.  Moreover, applications that use streamed transfer must organize data in the message incrementally so that the content does not have forward dependencies.  In many cases, there is a tradeoff between being able to stream content and having the smallest possible transfer size for that content.

Tooling

Tooling represents the support for an encoding by third-party applications for development, diagnosis, and other activities.  There has been a particularly large investment in providing tools and software for working with messages encoded in the POX format.

POX

Next time: Creating Custom Bindings

Comments

  • Anonymous
    May 24, 2006
    Today's post is a light entrée covering the IDefaultCommunicationTimeouts interface.  This interface...
  • Anonymous
    June 06, 2006
    Today continues the series I started last week about the standard bindings. The previous article covered...
  • Anonymous
    July 21, 2006
    Nicholas Allen has some excellent posts about WCF where he gets into a lot of the nitty-gritty and explains...
  • Anonymous
    July 24, 2006
    I still get a lot of hits for the series of documentation articles I did back in April and May.  All...
  • Anonymous
    January 03, 2007
    I started this blog back in February hoping to produce a daily post throughout the entire month. I had