The Basic Composition of a WCF Application
A typical WCF application involve three interrelated software components:
• The WCF Service assembly: This *.dll contains the classes and interfaces that represent the
overall functionality you are exposing to external callers.
• The WCF Service host: This software module is the entity that hosts your WCF service
assembly.
• The WCF client: This is the application that accesses the service’s functionality through an
intervening proxy.
The WCF service assembly is a ‘normal’ .NET class library defining a set of types. However, these types are
decorated with numerous new WCF-specific attributes. Using these attributes, you can control data type
representation, control which aspects of a WCF service are accessible to callers, and more.
The service host can be any .NET *.exe assembly. You could expose WCF services from a Windows Service,
a simple console application, or via a desktop GUI (Windows Forms, WPF). You can also host WCF objects
using IIS. In this case, you have no need to build the host manually. Vista machines can host WCF services
using the integrated Windows Activation Service (WAS).
Regardless of the hosting type, it will need to specify the necessary remoting infrastructure. These include
endpoints, transport layers, dynamic discovery of metadata, and so on. This sort of information can either be
hardcoded within the host assembly or specified via an external * .config file. Most WCF apps will opt for *.
config file as this allows you to change the plumbing without recompiling / redeploying your software.
Like a .NET remoting or XML web service client, WCF clients communicate with WCF services using an
intervening proxy. Any type of .NET application can be the client of a WCF service, including other WCF
services. Client side plumbing can also configured using *.config files or using 100% code.
The following diagram illustrates the high-level composition of a WCF application. Beneath the scenes are
several lower-level details used to represent the required plumbing (factories, channels, listeners, and so on).
Each of these low-level details are most often hidden from view; however, they can be extended or
customized if required.
The ABC’s of WCF
Hosts and clients communicate by agreeing on the ABC’s that describe the WCF service’s functionality:
• Address: The location of the service. In code, this is represented with a System.Uri type, but the
value is typically stored in *.config files.
• Binding: WCF ships with a number of different bindings that specify network protocols,
encoding mechanisms, and the transport layer.
• Contract: A description of each method exposed from the WCF service.
A new WCF service project typically begins by defining and implementing contracts. After that point, you
typically select the binding you wish to use to allow external callers to communicate with the service.
Finally, you will specify an address. As you will see, the format of an address will differ based on your
choice of bindings.
A typical WCF application involve three interrelated software components:
• The WCF Service assembly: This *.dll contains the classes and interfaces that represent the
overall functionality you are exposing to external callers.
• The WCF Service host: This software module is the entity that hosts your WCF service
assembly.
• The WCF client: This is the application that accesses the service’s functionality through an
intervening proxy.
The WCF service assembly is a ‘normal’ .NET class library defining a set of types. However, these types are
decorated with numerous new WCF-specific attributes. Using these attributes, you can control data type
representation, control which aspects of a WCF service are accessible to callers, and more.
The service host can be any .NET *.exe assembly. You could expose WCF services from a Windows Service,
a simple console application, or via a desktop GUI (Windows Forms, WPF). You can also host WCF objects
using IIS. In this case, you have no need to build the host manually. Vista machines can host WCF services
using the integrated Windows Activation Service (WAS).
Regardless of the hosting type, it will need to specify the necessary remoting infrastructure. These include
endpoints, transport layers, dynamic discovery of metadata, and so on. This sort of information can either be
hardcoded within the host assembly or specified via an external * .config file. Most WCF apps will opt for *.
config file as this allows you to change the plumbing without recompiling / redeploying your software.
Like a .NET remoting or XML web service client, WCF clients communicate with WCF services using an
intervening proxy. Any type of .NET application can be the client of a WCF service, including other WCF
services. Client side plumbing can also configured using *.config files or using 100% code.
The following diagram illustrates the high-level composition of a WCF application. Beneath the scenes are
several lower-level details used to represent the required plumbing (factories, channels, listeners, and so on).
Each of these low-level details are most often hidden from view; however, they can be extended or
customized if required.
The ABC’s of WCF
Hosts and clients communicate by agreeing on the ABC’s that describe the WCF service’s functionality:
• Address: The location of the service. In code, this is represented with a System.Uri type, but the
value is typically stored in *.config files.
• Binding: WCF ships with a number of different bindings that specify network protocols,
encoding mechanisms, and the transport layer.
• Contract: A description of each method exposed from the WCF service.
A new WCF service project typically begins by defining and implementing contracts. After that point, you
typically select the binding you wish to use to allow external callers to communicate with the service.
Finally, you will specify an address. As you will see, the format of an address will differ based on your
choice of bindings.
The Basic Composition of a WCF Application
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services