What Is Windows Communication Foundation?

The global acceptance of Web services, which includes standard protocols for application-to-
application communication, has changed software development. For example, the functions that Web
services now provide include security, distributed transaction coordination, and reliable
communication. The benefits of the changes in Web services should be reflected in the tools and
technologies that developers use. Windows Communication Foundation (WCF) is designed to offer a
manageable approach to distributed computing, broad interoperability, and direct support for
service orientation.

WCF simplifies development of connected applications through a new service-oriented programming

model. WCF supports many styles of distributed application development by providing a layered
architecture. At its base, the WCF channel architecture provides asynchronous, untyped message-
passing primitives. Built on top of this base are protocol facilities for secure, reliable, transacted data
exchange and broad choice of transport and encoding options.

The typed programming model (called the service model) is designed to ease the development of
distributed applications and to provide developers with expertise in ASP.NET Web services, .NET
Framework remoting, and Enterprise Services, and who are coming to WCF with a familiar
development experience. The service model features a straightforward mapping of Web services
concepts to those of the .NET Framework common language runtime (CLR), including flexible and
extensible mapping of messages to service implementations in languages such as Visual C# or Visual
Basic. It includes serialization facilities that enable loose coupling and versioning, and it provides
integration and interoperability with existing .NET Framework distributed systems technologies such as
Message Queuing (MSMQ), COM+, ASP.NET Web services, Web Services Enhancements (WSE), and a
number of other functions.

Problem Example

The following example illustrates some of the problems that WCF addresses. A car rental company
decides to create a new application for reserving cars. The creators of this rental car reservation
application know that the business logic it implements must be accessible by other software running
both inside and outside their company. Accordingly, they decide to build it in a service-oriented style,
with the application’s logic exposed to other software through a well-defined set of services. To
implement these services, and thus communicate with other software, the new application will use
WCF.
Over its lifetime, the rental car reservation application will likely be accessed by a range of other
applications. When it is designed, however, the architects of the rental car reservation application
know that its business logic will be accessed, as shown in the preceding figure, by three other kinds of
software:

• A call center client application running on the Windows desktops that are used by employees
in the organization’s call center. Created specifically for the new reservations system, this
application will also be built using the Microsoft .NET Framework and WCF. This application is
not truly distinct from the new rental car reservation application, because its only purpose is
to act as a client for the new system. From a service-oriented perspective, it is just another
client for the reservation system’s business logic.

• An existing reservation application built on a J2EE server running on a non-Windows system.

Due to a recent merger with another car rental firm, this existing system must be able to
access the new application’s logic to provide customers of the merged firms with a unified
experience.

• Partner applications running on a variety of platforms, each located within a company that has
a business arrangement with the car rental firm. Partners might include travel agencies,
airlines, and others that have a business requirement to make car rental reservations.

The diverse communication requirements for the new rental car reservation application are not simple.
For interactions with the call center client application, for instance, performance is important, while
interoperability is straightforward, because both are built on the .NET Framework. For communication
with the existing J2EE-based reservation application and with the diverse partner applications,
however, interoperability becomes the highest goal. The security requirements are also quite different,
varying across local Windows-based applications, a J2EE-based application running on another
operating system, and a variety of partner applications coming in across the Internet. Even
transactional requirements might vary, with only the internal applications being allowed to make
transactional requests. How can these diverse business and technical requirements be met without
exposing the creators of the new application to unmanageable complexity?

WCF is designed for this diverse but realistic scenario and is the default technology for Windows
applications that expose and access services. This topic provides an introduction to WCF, examining
what it provides and showing how it is used. Throughout this introduction, the scenario just described
will serve as an example. The goal is to make clear what WCF is, show what problems it solves, and
illustrate how it solves those problems.

Addressing the Problem

The foundation for new Windows-based applications is the .NET Framework. Accordingly, WCF is
implemented primarily as a set of classes on top of the .NET Framework CLR. Because it extends their
familiar environment, WCF enables developers who create object-oriented applications using the .NET
Framework today to also build service-oriented applications in a familiar way.

The figure shows a view of a WCF client and service. The two interact using SOAP, the WCF native
message representation, so even though the figure shows both parties built on WCF, this is not
required. WCF is built on .NET Framework 2.0.

As the scenario described earlier suggests, WCF addresses a range of challenges for communicating
applications. Three things stand out, however, as the most important aspects of WCF:

• Unification of existing .NET Framework communication technologies.

• Support for cross-vendor interoperability, including reliability, security, and transactions.

• Explicit service orientation.

Unification of Microsoft Distributed Computing Technologies

In the absence of WCF, the development team that implements the rental car application would need
to choose the right distributed technology from the multiple choices offered by the .NET Framework.
Yet given the diverse requirements of this application, no single technology would fit the
requirements. Instead, the application would probably use multiple existing .NET Framework
technologies, such as the following:
 • ASP.NET Web services (ASMX). An option for communicating with the J2EE-based existing
reservation application and with the partner applications across the Internet. Given that basic
Web services are supported today on most platforms, this was the most direct way to achieve
cross-vendor interoperability before the release of WCF.

• .NET Framework remoting. An option for communication with the call center application,
because both are built on the .NET Framework. Remoting is designed expressly for tightly
coupled .NET-to-.NET communication, so it offers a seamless and straightforward development
experience for applications in the local network.

• Enterprise Services. Used by the rental car reservation application for managing object
lifetimes and defining distributed transactions. These functions could be useful in
communicating and integrating with any of the other applications in this scenario, but
Enterprise Services supports only a limited set of communication options.

• WSE. Could be used along with ASMX to communicate with the J2EE-based reservation
application and with the partner applications. Because it implements more recently defined
Web services agreements, known collectively as the WS-* specifications, WSE allows for more
flexible Web services security, as long as all applications involved support compatible versions
of these new specifications.

• Microsoft Message Queuing (MSMQ). Used to communicate with Windows-based partner

applications that require guaranteed data delivery as well as decoupling of workloads and
application lifetimes. The durable messaging that Message Queuing provides is typically the
best solution for intermittently connected applications.

Built on .NET Framework, the rental car reservation application must use more than one of these
communication technologies to meet its requirements. Although this is technically possible, the
resulting application would be complex to implement and challenging to maintain.

With WCF, the solution is much easier to implement. As the figure shows, WCF can be used for all the
situations previously described. Accordingly, the rental car reservation application can use this single
technology for all of its application-to-application communication. The following shows how WCF
addresses each of these requirements:

• Because WCF can communicate using Web services, interoperability with other platforms that
also support SOAP, such as the leading J2EE-based application servers, is straightforward.

• You can also configure and extend WCF to communicate with Web services using messages
not based on SOAP, for example, simple XML formats like RSS.

• Performance is of paramount concern for most businesses. WCF is developed with the goal of
being one of the fastest distributed application platform developed by Microsoft. For a high-
 level performance comparison between WCF and other Microsoft .NET distributed
communication technologies, see http://go.microsoft.com/fwlink/?LinkId=94274.

• To allow optimal performance when both parties in a communication are built on WCF, the
wire encoding used in this case is an optimized binary version of an XML Information Set.
Messages still conform to the data structure of a SOAP message, but their encoding uses a
binary representation of that data structure rather than the standard angle-brackets-and-text
format of the XML 1.0 text encoding. Using this option makes sense for communicating with
the call center client application, because it is also built on WCF, and performance is an
important concern.

• Managing object lifetimes, defining distributed transactions, and other aspects of Enterprise
Services are now provided by WCF. They are available to any WCF-based application, which
means that the rental car reservation application can use them with any of the other
applications it communicates with.

• Because it supports a large set of the WS-* specifications, WCF helps provide reliability,
security, and transactions when communicating with any platform that also supports these
specifications.

• The WCF option for queued messaging, built on Message Queuing, allows applications to use
persistent queuing without using another set of application programming interfaces.

The result of this unification is greater functionality and significantly reduced complexity.

Interoperability with Applications Built on Other Technologies

While WCF introduces a new development environment for distributed applications, it is designed to
interoperate well with the non-WCF applications. There are two important aspects to WCF
interoperability: interoperability with other platforms, and interoperability with the Microsoft
technologies that preceded WCF. The following section describes both.

Interoperability with Other Web Services Platforms

Enterprises today typically have systems and applications that they purchased from a range of
suppliers. In the rental car application, for instance, communication is required with various other
software applications written in various languages and running on various operating systems.

Because WCF’s fundamental communication mechanism is SOAP-based Web services, WCF-based

applications can communicate with other software running in a variety of contexts. An application built
on WCF can interact with all of the following:

• WCF-based applications running in a different process on the same Windows machine.

• WCF-based applications running on another Windows machine.

 • Applications built on other technologies, such as J2EE application servers, that support
standard Web services. These applications can be running on Windows machines or on
machines running other operating systems.

To allow more than just basic communication, WCF implements Web services technologies defined by
the WS-* specifications. All of these specifications were originally defined by Microsoft, IBM, and other
vendors working together. As the specifications become stable, ownership often passes to standards
bodies, such as the World Wide Web Consortium (W3C) or the Organization for the Advancement of
Structured Information Standards (OASIS). These specifications address several areas, including basic
messaging, security, reliability, transactions, and working with a service’s metadata. For more
information, see Interoperability and Integration with Windows Communication Foundation. For more
information about advanced Web services specifications, see http://go.microsoft.com/fwlink/?
LinkId=86603.

Grouped by function, those specifications cover:

• Messaging: SOAP is the foundation for Web services and defines a basic envelope that
contains header and a body sections. WS-Addressing defines additions to the SOAP header for
addressing SOAP messages, which frees SOAP from relying on the underlying transport
protocol, such as HTTP, to carry addressing information. Message Transmission Optimization
Mechanism (MTOM) defines an optimized transmission format for SOAP messages with large
binary data contents based on the XML-binary Optimized Packaging (XOP) specification.

• Metadata: The Web Services Description Language (WSDL) defines a standard language for
specifying services and various aspects of how those services can be used. WS-Policy allows
specification of more dynamic aspects of a service’s behavior that cannot be expressed in
WSDL, such as a preferred security option. WS-MetadataExchange allows a client to directly
request descriptive information about a service, such as its WSDL and its policies, using SOAP.

• Security: WS-Security, WS-SecureConversation, WS-Trust, and WS-Federation all define

additions to SOAP messages for providing authentication, data integrity, data privacy, and
other security features.

• Reliability: WS-Reliable Messaging defines additions to the SOAP header that allow reliable
end-to-end communication, even when one or more Web services intermediaries must be
traversed.

• Transactions: Built on WS-Coordination, WS-Atomic Transaction allows coordinating two-phase

commit transactions in the context of Web services conversations.

The rental car reservation application would likely use several of these more advanced technologies.
For example, WS-Addressing is essential whenever SOAP is used over a transport mechanism other
than HTTP, which might be the case for communication with the .NET Framework-based call center
client application. WCF relies on WS-Policy and WS-Metadata Exchange to discover whether the
system it is communicating with is also using WCF and for other things. Reliable communication is
essential for most situations, so it is likely that WS-Reliable Messaging would be used to interact with
many of the other applications in this scenario. Similarly, you might also use WS-Security and the
related specifications for securing the communication with one or more of the applications, because all
would require some kind of protection against unauthorized access or message modification and
interception. For the applications that require transaction integration with the rental car reservation
system, WS-Atomic Transaction would be essential. Finally, MTOM could be used whenever an
optimized wire format for binary data is necessary (for instance for pictures of fleet examples), and
both sides of the communication supported this option.

The key point is that WCF implements interoperable Web services complete with cross-platform
security, reliability, transactions, and other services. To provide maximum throughput, WCF-to-WCF
communication can be significantly optimized, but all other communication uses standard Web
services protocols. In fact, it is possible for a single application to expose its services to both kinds of
clients.

Interoperability with Microsoft Technologies

Many Microsoft customers have made significant investments in the .NET Framework technologies that
WCF includes. Protecting those investments was a fundamental goal of WCF’s designers. Installing
WCF does not break existing technology, so there is no requirement that organizations change existing
applications to use it. A clear upgrade path is provided, however, and wherever possible, WCF
interoperates with those earlier technologies.

For example, both WCF and ASMX use SOAP, so WCF-based applications can directly interoperate with
those built on ASMX. Existing Enterprise Services applications can also be wrapped with WCF
interfaces, allowing them to interoperate with applications built on WCF. And because persistent
queuing in WCF relies on MSMQ, WCF-based applications can interoperate directly with non-WCF-
based applications built using native MSMQ interfaces. In the rental car reservations application,
software built using any of these earlier technologies could directly connect to and use the new
system’s WCF-based services.

Interoperability is not always possible, however. For example, even though WSE 1.0 and WSE 2.0
implement some of the same WS-* specifications as WCF, these earlier technologies implement earlier
versions of the specifications. Version 3.0 of WSE does allow interoperability with WCF, but earlier
versions do not. For more information about interoperability, see Migrating WSE 3.0 Web Services to
WCF.

Interoperability with Other XML Protocols

The future of the Internet is not predictable and the technologies used today may evolve or be
replaced. Today, a popular trend in building Web-centric applications (called by many "Web 2.0"), is
an application model based on communication using only simple XML formats that are not SOAP-based
and exclusively rely on HTTP as a transport and as an application protocol. For example, the
Representational State Transfer (REST) architectural style has no notion of user-defined operations for
dealing with data. Instead, application state is associated with HTTP URLs and HTTP methods (such as
PUT, POST, DELETE, and GET). This approach is in contrast to the creation of user-defined procedures
or functions that most developers are familiar with in an enterprise environment. However, the REST
approach is of value in scenarios where services must function as the back end of Web 2.0
applications.

REST is just one example of an evolving Web 2.0 technology. In this environment of experimental
programming models and ongoing reinterpretation and refinement of standards, flexibility is required
to cope with unforeseeable changes. WCF is flexible. For example, while WCF uses SOAP as an
underlying structure, it is not bound to using SOAP for wire communication. In fact, WCF can be
configured to process "plain" XML data that is not wrapped in a SOAP envelope. WCF can also be
extended to support specific XML formats, such as ATOM (a popular RSS standard), and even non-XML
formats, such as JavaScript Object Notation (JSON). This flexibility ensures that code written today
will be valid in the future, even if protocols change or are replaced. Therefore, WCF was designed for
the present and the future.

Fundamental Windows Communication Foundation Concepts

This document provides a high-level view of the Windows Communication Foundation (WCF)
architecture. It is intended to explain key concepts and how they fit together. For a tutorial on
creating the simplest version of a WCF service and client, see Getting Started Tutorial. To learn WCF
programming, see Basic WCF Programming.

WCF Fundamentals

Windows Communication Foundation (WCF) is a runtime and a set of APIs for creating systems that
send messages between services and clients. The same infrastructure and APIs are used to create
applications that communicate with other applications on the same computer system or on a system
that resides in another company and is accessed over the Internet.

Messaging and Endpoints

WCF is based on the notion of message-based communication, and anything that can be modeled as a
message (for example, an HTTP request or an MSMQ message) can be represented in a uniform way
in the programming model. This enables a unified API across different transport mechanisms.

The model distinguishes between clients, which are applications that initiate communication, and
services, which are applications that wait for clients to communicate with them and respond to that
communication. A single application can act as both a client and a service.

Messages are sent between endpoints. Endpoints are places where messages are sent or received (or
both), and they define all the information required for the message exchange. A service exposes one
or more application endpoints (as well as zero or more infrastructure endpoints), and the client
generates an endpoint that is compatible with one of the service's endpoints.
An endpoint describes in a standard-based way where messages should be sent, how they should be
sent, and what the messages should look like. A service can expose this information as metadata that
clients can process to generate appropriate WCF clients and communication stacks.

Communication Protocols
One required element of the communication stack is the transport protocol. Messages can be sent
over intranets and the Internet using common transports, such as HTTP and TCP. Other transports are
included that support communication with Microsoft Message Queuing (MSMQ) applications and nodes
on a Peer Networking mesh. More transport mechanisms can be added using the built-in extension
points of WCF.

Another required element in the communication stack is the encoding that specifies how any given
message is formatted. WCF provides the following encodings:

• Text encoding, an interoperable encoding.

• Message Transmission Optimization Mechanism (MTOM) encoding, which is an interoperable

way for efficiently sending unstructured binary data to and from a service.

• Binary encoding for efficient transfer.

More encoding mechanisms (for example, a compression encoding) can be added using the built-in
extension points of WCF.

Message Patterns
WCF supports several messaging patterns, including request-reply, one-way, and duplex
communication. Different transports support different messaging patterns, and thus affect the types of
interactions that they support. The WCF APIs and runtime also help you to send messages securely
and reliably.

WCF Terms

Other concepts and terms used in the WCF documentation include the following.

message
A message is a self-contained unit of data that may consist of several parts, including a body
and headers.
service
A service is a construct that exposes one or more endpoints, with each endpoint exposing one
or more service operations.
endpoint
An endpoint is a construct at which messages are sent or received (or both). It comprises a
location (an address) that defines where messages can be sent, a specification of the
communication mechanism (a binding) that described how messages should be sent, and a
 definition for a set of messages that can be sent or received (or both) at that location (a
service contract) that describes what message can be sent.
An WCF service is exposed to the world as a collection of endpoints.
application endpoint
An endpoint exposed by the application and that corresponds to a service contract
implemented by the application.
infrastructure endpoint
An endpoint that is exposed by the infrastructure to facilitate functionality that is needed or
provided by the service that does not relate to a service contract. For example, a service
might have an infrastructure endpoint that provides metadata information.
address
An address specifies the location where messages are received. It is specified as a Uniform
Resource Identifier (URI). The URI schema part names the transport mechanism to use to
reach the address, such as HTTP and TCP. The hierarchical part of the URI contains a unique
location whose format is dependent on the transport mechanism.
The endpoint address enables you to create unique endpoint addresses for each endpoint in a
service, or under certain conditions share an address across endpoints. The following example
shows an address using the HTTPS protocol with a non-default port:

Copy Code
HTTPS://cohowinery:8005/ServiceModelSamples/CalculatorService
binding
A binding defines how an endpoint communicates to the world. It is constructed of a set of
components called binding elements that "stack" one on top of the other to create the
communication infrastructure. At the very least, a binding defines the transport (such as HTTP
or TCP) and the encoding being used (such as text or binary). A binding can contain binding
elements that specify details like the security mechanisms used to secure messages, or the
message pattern used by an endpoint. For more information, see Configuring Windows
Communication Foundation Services.
binding element
A binding element represents a particular piece of the binding, such as a transport, an
encoding, an implementation of an infrastructure-level protocol (such as WS-
ReliableMessaging), or any other component of the communication stack.
behaviors
A behavior is a component that controls various run-time aspects of a service, an endpoint, a
particular operation, or a client. Behaviors are grouped according to scope: common behaviors
affect all endpoints globally, service behaviors affect only service-related aspects, endpoint
behaviors affect only endpoint-related properties, and operation-level behaviors affect
particular operations. For example, one service behavior is throttling, which specifies how a
service reacts when an excess of messages threaten to overwhelm its handling capabilities. An
endpoint behavior, on the other hand, controls only aspects relevant to endpoints, such as
how and where to find a security credential.
system-provided bindings
WCF includes a number of system-provided bindings. These are collections of binding
elements that are optimized for specific scenarios. For example, the WSHttpBinding is
designed for interoperability with services that implement various WS-* specifications. These
predefined bindings save time by presenting only those options that can be correctly applied
to the specific scenario. If a predefined binding does not meet your requirements, you can
create your own custom binding.
configuration versus coding
Control of an application can be done either through coding, through configuration, or through
a combination of both. Configuration has the advantage of allowing someone other than the
developer (for example, a network administrator) to set client and service parameters after
the code is written and without having to recompile. Configuration not only enables you to set
values like endpoint addresses, but also allows further control by enabling you to add
endpoints, bindings, and behaviors. Coding allows the developer to retain strict control over all
components of the service or client, and any settings done through the configuration can be
inspected and if needed overridden by the code.
service operation
A service operation is a procedure defined in a service's code that implements the functionality
for an operation. This operation is exposed to clients as methods on a WCF client. The method
may return a value, and may take an optional number of arguments, or take no arguments,
and return no response. For example, an operation that functions as a simple "Hello" can be
used as a notification of a client's presence and to begin a series of operations.
service contract
The service contract ties together multiple related operations into a single functional unit. The
contract can define service-level settings, such as the namespace of the service, a
corresponding callback contract, and other such settings. In most cases, the contract is
defined by creating an interface in the programming language of your choice and applying the
ServiceContractAttribute attribute to the interface. The actual service code results by
implementing the interface.
operation contract
An operation contract defines the parameters and return type of an operation. When creating
an interface that defines the service contract, you signify an operation contract by applying
the OperationContractAttribute attribute to each method definition that is part of the contract.
The operations can be modeled as taking a single message and returning a single message, or
as taking a set of types and returning a type. In the latter case, the system will determine the
format for the messages that need to be exchanged for that operation.
message contract
A message contract describes the format of a message. For example, it declares whether
message elements should go in headers versus the body, what level of security should be
applied to what elements of the message, and so on.
fault contract
 A fault contract can be associated with a service operation to denote errors that can be
returned to the caller. An operation can have zero or more faults associated with it. These
errors are SOAP faults that are modeled as exceptions in the programming model.
data contract
The data types a service uses must be described in metadata to enable others to interoperate
with the service. The descriptions of the data types are known as the data contract, and the
types can be used in any part of a message, for example, as parameters or return types. If
the service is using only simple types, there is no need to explicitly use data contracts.
hosting
A service must be hosted in some process. A host is an application that controls the lifetime of
the service. Services can be self-hosted or managed by an existing hosting process.
self-hosted service
A self-hosted service is one that runs within a process application that the developer created.
The developer controls its lifetime, sets the properties of the service, opens the service (which
sets it into a listening mode), and closes the service.
hosting process
A hosting process is an application that is designed to host services. These include Internet
Information Services (IIS), Windows Activation Services (WAS), and Windows Services. In
these hosted scenarios, the host controls the lifetime of the service. For example, using IIS
you can set up a virtual directory that contains the service assembly and configuration file.
When a message is received, IIS starts the service and controls its lifetime.
instancing
A service has an instancing model. There are three instancing models: "single," in which a
single CLR object services all the clients; "per call," in which a new CLR object is created to
handle each client call; and "per session," in which a set of CLR objects are created, one for
each separate session. The choice of an instancing model depends on the application
requirements and the expected usage pattern of the service.
client application
A client application is a program that exchanges messages with one or more endpoints. The
client application begins by creating an instance of a WCF client and calling methods of the
WCF client. It is important to note that a single application can be both a client and a service.
channel
A channel is a concrete implementation of a binding element. The binding represents the
configuration, and the channel is the implementation associated with that configuration.
Therefore, there is a channel associated with each binding element. Channels stack on top of
each other to create the concrete implementation of the binding: the channel stack.
WCF client
A WCF client is a client-application construct that exposes the service operations as methods
(in the .NET Framework programming language of your choice, such as Visual Basic or Visual
C#). Any application can host a WCF client, including an application that hosts a service.
Therefore, it is possible to create a service that includes WCF clients of other services.
 A WCF client can be automatically generated by using the ServiceModel Metadata Utility Tool
(Svcutil.exe) and pointing it at a running service that publishes metadata.
metadata
The metadata of a service describes the characteristics of the service that an external entity
needs to understand to communicate with the service. Metadata can be consumed by the
ServiceModel Metadata Utility Tool (Svcutil.exe) to generate a WCF client and accompanying
configuration that a client application can use to interact with the service.
The metadata exposed by the service includes XML schema documents, which define the data
contract of the service, and WSDL documents, which describe the methods of the service.
When enabled, metadata for the service is automatically generated by WCF by inspecting the
service and its endpoints. To publish metadata from a service, you must explicitly enable the
metadata behavior.
security
Security in WCF includes confidentiality (encryption of messages to prevent eavesdropping),
integrity (the means for detection of tampering with the message), authentication (the means
for validation of servers and clients), and authorization (the control of access to resources).
These functions are provided by either leveraging existing security mechanisms, such as TLS
over HTTP (also known as HTTPS), or by implementing one or more of the various WS-*
security specifications.
transport security mode
Security can be provided by one of three modes: transport mode, message security mode, and
transport with message credential mode. The transport security mode specifies that
confidentiality, integrity, and authentication are provided by the transport layer mechanisms
(such as HTTPS). When using a transport like HTTPS, this mode has the advantage of being
efficient in its performance, and well understood because of its prevalence on the Internet.
The disadvantage is that this kind of security is applied separately on each hop in the
communication path, making the communication susceptible to a "man in the middle" attack.
message security mode
Message security mode specifies that security is provided by implementing one or more of the
security specifications, such as the specification named "Web Services Security: SOAP
Message Security" (available at http://go.microsoft.com/fwlink/?LinkId=94684). Each
message contains the necessary mechanisms to provide security during its transit, and to
enable the receivers to detect tampering and to decrypt the messages. In this sense, the
security is encapsulated within every message, providing end-to-end security across multiple
hops. Because security information becomes part of the message, it is also possible to include
multiple kinds of credentials with the message (these are referred to as claims). This approach
also has the advantage of enabling the message to travel securely over any transport,
including multiple transports between its origin and destination. The disadvantage of this
approach is the complexity of the cryptographic mechanisms employed, resulting in
performance implications.
transport with message credential security mode
 This mode uses the transport layer to provide confidentiality, authentication, and integrity of
the messages, while each of the messages can contain multiple credentials (claims) required
by the receivers of the message.
WS-*
Shorthand for the growing set of Web Service (WS) specifications, such as WS-Security, WS-
ReliableMessaging, and so on, that are implemented in WCF.

Windows Communication Foundation Architecture

The following graphic illustrates the major layers of the Windows Communication Foundation (WCF)
architecture.

WCF Architecture

Contracts and Descriptions

Contracts define various aspects of the message system. The data contract describes every parameter
that makes up every message that a service can create or consume. The message parameters are
defined by XML Schema definition language (XSD) documents, enabling any system that understands
XML to process the documents. The message contract defines specific message parts using SOAP
protocols, and allows finer-grained control over parts of the message, when interoperability demands
such precision. The service contract specifies the actual method signatures of the service, and is
distributed as an interface in one of the supported programming languages, such as Visual Basic or
Visual C#.

Policies and bindings stipulate the conditions required to communicate with a service. For example,
the binding must (at a minimum) specify the transport used (for example, HTTP or TCP), and an
encoding. Policies include security requirements and other conditions that must be met to
communicate with a service.

Service Runtime
The service runtime layer contains the behaviors that occur only during the actual operation of the
service, that is, the runtime behaviors of the service. Throttling controls how many messages are
processed, which can be varied if the demand for the service grows to a preset limit. An error behavior
specifies what occurs when an internal error occurs on the service, for example, by controlling what
information is communicated to the client. (Too much information can give a malicious user an
advantage in mounting an attack.) Metadata behavior governs how and whether metadata is made
available to the outside world. Instance behavior specifies how many instances of the service can be
run (for example, a singleton specifies only one instance to process all messages). Transaction
behavior enables the rollback of transacted operations if a failure occurs. Dispatch behavior is the
control of how a message is processed by the WCF infrastructure.

Extensibility enables customization of runtime processes. For example, message inspection is the
facility to inspect parts of a message, and parameter filtering enables preset actions to occur based on
filters acting on message headers.

Messaging
The messaging layer is composed of channels. A channel is a component that processes a message in
some way, for example, by authenticating a message. A set of channels is also known as a channel
stack. Channels operate on messages and message headers. This is different from the service runtime
layer, which is primarily concerned about processing the contents of message bodies.

There are two types of channels: transport channels and protocol channels.

Transport channels read and write messages from the network (or some other communication point
with the outside world). Some transports use an encoder to convert messages (which are represented
as XML Infosets) to and from the byte stream representation used by the network. Examples of
transports are HTTP, named pipes, TCP, and MSMQ. Examples of encodings are XML and optimized
binary.

Protocol channels implement message processing protocols, often by reading or writing additional
headers to the message. Examples of such protocols include WS-Security and WS-Reliability.

The messaging layer illustrates the possible formats and exchange patterns of the data. WS-Security
is an implementation of the WS-Security specification enabling security at the message layer. The WS-
Reliable Messaging channel enables the guarantee of message delivery. The encoders present a
variety of encodings that can be used to suit the needs of the message. The HTTP channel specifies
that the HyperText Transport Protocol is used for message delivery. The TCP channel similarly
specifies the TCP protocol. The Transaction Flow channel governs transacted message patterns. The
Named Pipe channel enables interprocess communication. The MSMQ channel enables interoperation
with MSMQ applications.

Hosting and Activation

In its final form, a service is a program. Like other programs, a service must be run in an executable.
This is known as a self-hosted service.

Services can also be hosted, or run in an executable managed by an external agent, such as IIS or
Windows Activation Service (WAS). WAS enables WCF applications to be activated automatically when
deployed on a computer running WAS. Services can also be manually run as executables (.exe files). A
service can also be run automatically as a Windows service. COM+ components can also be hosted as
WCF services.