WCF Tutorial Objective
- Review the role of interface-based programming
- Review the role of XML web services
- Define Service-Oriented Architectures (SOAs)
- Review the core distributed APIs of the Microsoft Windows OS
- Understand the motivation behind Windows Communication Foundation (WCF)
- Take a first look at building and testing WCF services
- Learn to create self-hosting WCF services
- Declaratively define hosting logic within *.config files
- Define hosting logic programmatically
- Understand the role of Metadata Exchange (MEX)
- Generate and make use of client proxies
- Learn to host WCF services in a Windows service
- Learn to host WCF services in IIS virtual directories
- Define and invoke ‘one-way’ method operations
- Learn to invoke WCF service methods asynchronously
Building a distributed system is a very common task for many programmers. However, doing so involves confronting numerous design challenges. In this chapter, you will review two key aspects of many distributed systems (interfaces and XML web services), followed by an overview of Service-Oriented Architectures (SOAs). Also, you will survey several core distributed APIs found within the Windows OS. With this historical background in place, the remainder of this chapter will introduce you to the Windows Communication Foundation (WCF) API. Here you will learn about the problems WCF attempts to solve, study the ABC’s (addresses, bindings, and contracts) of building a WCF application, and explore some common WCF development tools
The information presented here will function as the backbone for the remainder of the class.
A Working Definition of Windows Communication Foundation (WCF)
To begin your examination of WCF, you will start with a review of common distributed programming practices and previously distributed APIs. This is important, given that WCF leverages many of the distributed concepts / APIs you may have used in the past.
WCF is a .NET 3.0 (and higher) API that allows you to build distributed systems. WCF is unique in that you can select from many types of bindings. This fact alone makes WCF a very flexible framework. A single WCF service could be exposed via an HTTP binding for outwardly facing callers or via a TCP binding for in-house callers. The underlying plumbing details can be relegated to *.config files, which make it very simple to change bindings and other details on the fly.
WCF makes extensive use of interface-based programming techniques. When you define a WCF service, you typically begin by defining the interfaces that model the functionality callers can expect to find. These .NET interfaces could be used by the runtime to generate WSDL definitions based on your choice of bindings.
In addition, WCF makes heavy use of .NET attributes to qualify how the runtime should handle client / service interactions. Similar to the .NET remoting layer / XML web services, WCF attributes are used to control data formatting, binding operations, and more. Recall that attributes are essentially code annotations. Attributes are useless unless another piece of software reflects over them. In this case, the ‘other piece of software’ could be the WCF runtime as well as WCF development tools.
WCF is heavily influenced by XML web services and Service-Oriented Architectures (SOAs) in general. Like an XML web service, WCF services make use of contracts and explicit boundaries and support the use of various WS-* specifications.
However, a WCF service does not have to use web-service-centric bindings. If you wish, you can opt for P2P bindings, named pipes, TCP bindings, and so on. The underlying binding is decoupled from the service itself. Therefore, changing bindings on the fly is very straightforward.
In a nutshell, as of .NET 3.0 (and higher), WCF is the preferred way to build new distributed systems. The original distributed .NET APIs (System.Runtime.Remoting, System.Web.Services, and so forth) are still supported. Furthermore, Visual Studio still has templates for ‘traditional’ ASP.NET web service project workspaces.
It is also possible to migrate existing XML web services / remoting applications into the WCF programming model. Doing so, however, may offer little benefit. In fact, it could entail a good amount of work.
This course does not cover migrating existing distributed systems into the WCF programming model. The class assumes you intend to build new WCF services, hosts, and clients. However, Appendix A illustrates how to interact with legacy COM+ components. You can read Appendix A if time / interest permits.
The .NET Framework SDK documentation provides details of migrating existing systems. If you are interested in migrating from .NET remoting to WCF, look up the article ‘From .NET Remoting to the Windows Communication Foundation (WCF)’. If you are interested in migrating from ASP.NET web services to WCF, look up the article ‘Migrating ASP.NET Web Services to WCF’.
Finally, be aware that this class will focus on the core aspects of the programming model, which will be commonplace to all of your WCF projects. Consult the .NET Framework SDK documentation for WCF topics not addressed in this course. The WCF section of the SDK documentation provides a number of excellent code examples, white papers, and tutorials. Simply look up the Windows Communication Foundation selection of the help system and dive in.
Copyright (c) 2008-2013. 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.