Windows Communication Foundation
Windows Communication Foundation (WCF) is an SDK for developing and deploying services on Windows. WCF provides a runtime environment for your services, enabling you to expose CLR types as services, and to consume other services as CLR types. Although in theory you could build services without WCF, in practice building services is significantly easier with WCF. WCF is Microsoft's implementation of a set of industry standards defining service interactions, type conversion, marshaling, and various protocols' management. Because of that, WCF provides interoperability between services. WCF provides developers with the essential off-the-shelf plumbing required by almost any application, and as such, it greatly increases productivity. The first release of WCF provides many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security. WCF also has an elegant extensibility model that you can use to enrich the basic offering. In fact, WCF itself is written using this extensibility model. Most all of the WCF functionality is included in a single assembly called System.ServiceModel.dll in the System.ServiceModel namespace.WCF Service
A service is a unit of functionality exposed to the world. In that respect, it is the next evolutionary step in the long journey from functions to objects to components to services. Service-orientation (SO) is an abstract set of principles and best practices for building SO applications. If you are unfamiliar with the principles of service-orientation, A service-oriented application (SOA) aggregates services into a single logical application similar to the way a component-oriented application aggregates components or an object-oriented application aggregates objects
The services can be local or remote, developed by multiple parties using any technology, versioned independently, and even execute on different timelines. Inside a service, you will find concepts such as languages, technologies, platforms, versions, and frameworks, yet between services, only prescribed communication patterns are allowed.
The client of a service is merely the party consuming its functionality. The client can be literally anythinga Windows Forms class, an ASP.NET page, or another service.
Clients and services interact by sending and receiving messages. Messages may transfer directly from client to service or via an intermediary. With WCF, all messages are SOAP messages.
Note that the messages are independent of transport protocolsunlike
Web services, WCF services may communicate over a variety of transports, not just HTTP. WCF clients
may interoperate with non-WCF services, and WCF services can interact with non-WCF clients. That said, typically if you develop both the client and the service, you could construct the application so that both ends require WCF to utilize WCF-specific advantages.
Because the making of the service is opaque from the outside, a WCF service typically exposes metadata
describing the available functionality and possible ways of communicating with the service. The metadata is published in a predefined, technology-neutral way, such as using WSDL over HTTP-GET, or an industry standard for metadata exchange. A non-WCF client can import the metadata to its native environment as native types. Similarly, a WCF client can import the metadata of a non-WCF service and consume it as native CLR classes and interfaces.
Every service is associated with an
address that defines where the service is, a binding that defines how
to communicate with the service, and a contract that defines what the
service does. This triumvirate governing the service is easy to
remember as the ABC of the service. WCF formalizes this relationship in
the form of an endpoint. The endpoint is the fusion of the Address,
Binding and a Contract. Every endpoint must have all three elements, and
the host exposes the endpoint. Logically, the endpoint is the service's
interface, and is analogous to a CLR or COM interface.WCF Adresses:
Every service must expose at least one business endpoint and each endpoint has exactly one contract. All endpoints
on a service have unique addresses, and a single service can expose
multiple endpoints. These endpoints can use the same or different
bindings and can expose the same or different contracts. There is
absolutely no relationship between the various endpoints a service
It is important to point out that nothing in the service
code pertains to its endpoints and they are always external to the
service code. You can configure endpoints either administratively using
a config file or programmatically.
In WCF, every service is associated with a unique address. The address provides two important elements: the location of the service and the transport protocol or transport schema used to communicate with the service. The location portion of the address indicates the name of the target machine, site, or network; a communication port, pipe, or queue; and an optional specific path or URI. A URI is a Universal Resource Identifier, and can be any unique string, such as the service name or a GUID.
WCF 1.0 supports the following transport schemas:
- Peer network
- IPC (Inter-Process Communication over named pipes)
There are multiple aspects of communication
with any given service, and there are many possible communication
patterns: messages can be synchronous request/reply or asynchronous
fire-and-forget; messages can be bidirectional; messages can be
delivered immediately or queued; and the queues can be durable or
volatile. There are many possible transport protocols for the messages,
such as HTTP (or HTTPS), TCP, P2P (peer network), IPC (named pipes), or
MSMQ. There are a few possible message encoding options: you can chose
plain text to enable interoperability, binary encoding to optimize
performance, or MTOM (Message Transport Optimization Mechanism) for large payloads. There are a few options for securing messages: you
can choose not to secure them at all, to provide transport-level
security only, to provide message-level privacy and security, and of
course there are numerous ways for authenticating and authorizing the
clients. Message delivery might be unreliable or reliable end-to-end
across intermediaries and dropped connections, and the messages might
be processed in the order they were sent or in the order they were
received. Your service might need to interoperate with other services
or clients that are only aware of the basic web service protocol, or
they may be capable of using the score of WS-* modern protocols such as
WS-Security and WS-Atomic Transactions. Your service may need to
interoperate with legacy clients over raw MSMQ messages, or you may
want to restrict your service to interoperate only with another WCF
service or client.
If you start counting all the possible
communication and interaction options, the number of permutations is
probably in the tens of thousands. Some of those choices may be
mutually exclusive, and some may mandate other choices. Clearly, both
the client and the service must be aligned on all these options in
order to communicate properly. Managing this level of complexity adds
no business value to most applications, and yet the productivity and
quality implications of making the wrong decisions are severe.
To simplify these choices and make them more manageable, WCF groups together a set of such communication aspects in bindings.
A binding is merely a consistent, canned set of choices regarding the
transport protocol, message encoding, communication pattern,
reliability, security, transaction propagation, and interoperability.
Ideally, you would extract all these "plumbing" aspects out of your
service code and allow the service to focus solely on the
implementation of the business logic. Binding enables you to use the
same service logic over drastically different plumbing.
You can use
the WCF-provided bindings as is, you can tweak their properties, or you
can write your own custom bindings from scratch. The service publishes
its choice of binding in its metadata, enabling clients to query for
the type and specific properties of the binding because the client must
use the exact same binding values as the service. A single service can
support multiple bindings on separate addresses.
WCF defines nine standard bindings:
- Basic binding Offered
by the BasicHttpBinding class, this is designed to expose a WCF service
as a legacy ASMX web service, so that old clients can work with new
services. When used by the client, this binding enables new WCF clients
to work with old ASMX services.
- TCP binding Offered by
the NetTcpBinding class, this uses TCP for cross-machine communication
on the intranet. It supports a variety of features, including
reliability, transactions, and security, and is optimized for
WCF-to-WCF communication. As a result, it requires both the client and
the service to use WCF.
- Peer network binding Offered
by the NetPeerTcpBinding class, this uses peer networking as a
transport. The peer network-enabled client and services all subscribe
to the same grid and broadcast messages to it.
- IPC binding Offered
by the NetNamedPipeBinding class, this uses named pipes as a transport
for same-machine communication. It is the most secure binding since it
cannot accept calls from outside the machine and it supports a variety
of features similar to the TCP binding.
- Web Service (WS) binding Offered
by the WSHttpBinding class, this uses HTTP or HTTPS for transport, and
is designed to offer a variety of features such as reliability,
transactions, and security over the Internet.
- Federated WS binding Offered
by the WSFederationHttpBinding class, this is a specialization of the
WS binding, offering support for federated security.
- Duplex WS binding Offered
by the WSDualHttpBinding class, this is similar to the WS binding
except it also supports bidirectional communication from the service to
the client .
- MSMQ binding Offered
by the NetMsmqBinding class, this uses MSMQ for transport and is
designed to offer support for disconnected queued calls.
- MSMQ integration binding Offered
by the MsmqIntegrationBinding class, this converts WCF messages to and
from MSMQ messages, and is designed to interoperate with legacy MSMQ
In WCF, all services expose contracts. The contract is a platform-neutral and standard way of describing what the service does. WCF defines four types of contracts.
- Service contracts Describe which operations the client can perform on the service.
- Data contracts Define which data types are passed to and from the service. WCF defines implicit contracts for built-in types such as int and string, but you can easily define explicit opt-in data contracts for custom types.
- Fault contracts Define which errors are raised by the service, and how the service handles and propagates errors to its clients.
- Message contracts Allow the service to interact directly with messages. Message contracts can be typed or untyped, and are useful in interoperability cases and when there is an existing message format you have to comply with. As a WCF developer, you should use message contracts only rarely.
The WCF service class cannot exist in a void. Every WCF service must be hosted in a Windows process called the host process.
A single host process can host multiple services, and the same service type can be hosted in multiple host processes. WCF makes no demand on whether or not the host process is also the client process. Obviously, having a separate process advocates fault and security isolation. It is also immaterial who provides the process or what kind of a process is involved. The host can be provided by IIS,
by the Widows Activation Service (WAS) on Windows Vista, or by the developer as part of the application.