The Role of WCF Contracts
When defining contracts, you typically do so by defining strongly typed CLR interfaces. The interfaces are
adorned with various WCF attributes to control how the runtime interacts with these types.
System.ServiceModel defines the basic attributes you will use on a day-to-day basis. More exotic attributes
are found within the System.Runtime.Serialization.dll assembly. They allow you to fine-tune how data is
represented.
Strictly speaking, you do not need to make use of interfaces to build a WCF contract, although interfaces are
preferred. It is possible to expose public members from a public class type using the correct attributes.
Once you define the WCF service interface, you will implement their members on a new class (or structure)
type using your language of choice. At this point, you simple flesh out the details of the contract
(communicate with a database, perform calculations, send e-mails, or what have you). You will learn how to
define and implement contracts a bit later in this chapter.
Examining WCF Binding Options
WCF ships with many predefined bindings, all of which are defined within the System.ServiceModel
namespace. Each is tailored to a specific remoting need. If none of these default binding fit the bill, you are
free to create your own by extending the CustomBinding type (something that will not be covered in this
course).
Simply put, a WCF binding specifies the following characteristics:
• The transport layer used to move data (HTTP, MSMQ, Named Pipes, TCP).
• The channels used by the transport (one-way fire and forget, request-reply, duplex).
• The encoding mechanism used to deal with the data itself (XML, binary, and so on).
• Any supported web service protocols, if permitted by the binding, such as WS-Security, WS-
Transactions, WS-Reliability, and so forth.
The BasicHttpBinding, WSHttpBinding, WSDualHttpBinding and WSFederationHttpBinding options are
geared to exposing a service type via XML web service protocols. Clearly, if you require the furthest reach
possible (multiple operating systems, multiple programming architectures such as COM, .NET, and JAVA
EE), these are the types to focus on. All of these types encode data based on XML representation and use
HTTP on the wire. Essentially, these bindings represent a new way to build an XML web service using WCF.
If all networked machines host .NET 3.0 (Windows XP, Windows Server 2003, or Windows Vista), you can
gain performance benefits by bypassing web service bindings and opting for a TCP binding. Again, the caller
and service must be .NET applications (which typically entails an inwardly facing application on the same
network). All data is encoded in a compact binary format. The client and service can make full use of the .
NET Common Type System.
If you are attempting to integrate with a MSMQ server, the NetMsmqBinding and MsmqIntegrationBinding
bindings are of immediate interest. These bindings support loosely coupled applications, failure isolation,
load leveling, and disconnected operations.
• NetMsmqBinding is the key type when all applications are using MSMQ on the .NET platform.
• MsmqIntegrationBinding allows a WCF app to interop with non-.NET apps that use MSMQ
such as COM objects or raw C++ applications.
This course will not examine how to build WCF services that interact with Microsoft Message Queue
(MSMQ). However, a later chapter will examine ‘reliable messaging’ using the WS-ReliableMessaging
specification. Consult the .NET Framework SDK documentation if you are interested in MSMQ integration
services. The topic ‘Queues in WCF’ is a good starting point.
Each WCF binding has a predefined set of default settings. At minimum, each binding will define a transport
protocol and message-encoding format. A binding’s defaults can be changed via configuration or code.
However, a particular binding may also have support for other features (transactions, security, reliable
messaging, and more).
Also, always remember that some ‘special features’ are not supported by every binding. Consider the
following table, which illustrates how the intrinsic WCF bindings address several important details regarding
their overall functionality.
Furthermore, your choice of binding will have a direct impact on the underlying transport layer. Consider the
following table, which illustrates how the choice of binding alters the underlying transportation layer. Net-
based bindings such as netTcpBinding can be configured to use SSL for secure transport.
Note that there is not a specific binding to interact with COM+ components (a.k.a. Enterprise Services).
Communicating with COM+ components often involves exposing types through a XML web service binding.
The ComSvcConfig.exe command line tool can be used to generate a WCF service, as well as a related *.config
file, to communicate with COM+ objects. Typically, this WCF service will be hosted within IIS.
Appendix A explains how to build WCF services that communicate with COM+ objects.
When defining contracts, you typically do so by defining strongly typed CLR interfaces. The interfaces are
adorned with various WCF attributes to control how the runtime interacts with these types.
System.ServiceModel defines the basic attributes you will use on a day-to-day basis. More exotic attributes
are found within the System.Runtime.Serialization.dll assembly. They allow you to fine-tune how data is
represented.
Strictly speaking, you do not need to make use of interfaces to build a WCF contract, although interfaces are
preferred. It is possible to expose public members from a public class type using the correct attributes.
Once you define the WCF service interface, you will implement their members on a new class (or structure)
type using your language of choice. At this point, you simple flesh out the details of the contract
(communicate with a database, perform calculations, send e-mails, or what have you). You will learn how to
define and implement contracts a bit later in this chapter.
Examining WCF Binding Options
WCF ships with many predefined bindings, all of which are defined within the System.ServiceModel
namespace. Each is tailored to a specific remoting need. If none of these default binding fit the bill, you are
free to create your own by extending the CustomBinding type (something that will not be covered in this
course).
Simply put, a WCF binding specifies the following characteristics:
• The transport layer used to move data (HTTP, MSMQ, Named Pipes, TCP).
• The channels used by the transport (one-way fire and forget, request-reply, duplex).
• The encoding mechanism used to deal with the data itself (XML, binary, and so on).
• Any supported web service protocols, if permitted by the binding, such as WS-Security, WS-
Transactions, WS-Reliability, and so forth.
The BasicHttpBinding, WSHttpBinding, WSDualHttpBinding and WSFederationHttpBinding options are
geared to exposing a service type via XML web service protocols. Clearly, if you require the furthest reach
possible (multiple operating systems, multiple programming architectures such as COM, .NET, and JAVA
EE), these are the types to focus on. All of these types encode data based on XML representation and use
HTTP on the wire. Essentially, these bindings represent a new way to build an XML web service using WCF.
If all networked machines host .NET 3.0 (Windows XP, Windows Server 2003, or Windows Vista), you can
gain performance benefits by bypassing web service bindings and opting for a TCP binding. Again, the caller
and service must be .NET applications (which typically entails an inwardly facing application on the same
network). All data is encoded in a compact binary format. The client and service can make full use of the .
NET Common Type System.
If you are attempting to integrate with a MSMQ server, the NetMsmqBinding and MsmqIntegrationBinding
bindings are of immediate interest. These bindings support loosely coupled applications, failure isolation,
load leveling, and disconnected operations.
• NetMsmqBinding is the key type when all applications are using MSMQ on the .NET platform.
• MsmqIntegrationBinding allows a WCF app to interop with non-.NET apps that use MSMQ
such as COM objects or raw C++ applications.
This course will not examine how to build WCF services that interact with Microsoft Message Queue
(MSMQ). However, a later chapter will examine ‘reliable messaging’ using the WS-ReliableMessaging
specification. Consult the .NET Framework SDK documentation if you are interested in MSMQ integration
services. The topic ‘Queues in WCF’ is a good starting point.
Each WCF binding has a predefined set of default settings. At minimum, each binding will define a transport
protocol and message-encoding format. A binding’s defaults can be changed via configuration or code.
However, a particular binding may also have support for other features (transactions, security, reliable
messaging, and more).
Also, always remember that some ‘special features’ are not supported by every binding. Consider the
following table, which illustrates how the intrinsic WCF bindings address several important details regarding
their overall functionality.
Furthermore, your choice of binding will have a direct impact on the underlying transport layer. Consider the
following table, which illustrates how the choice of binding alters the underlying transportation layer. Net-
based bindings such as netTcpBinding can be configured to use SSL for secure transport.
Note that there is not a specific binding to interact with COM+ components (a.k.a. Enterprise Services).
Communicating with COM+ components often involves exposing types through a XML web service binding.
The ComSvcConfig.exe command line tool can be used to generate a WCF service, as well as a related *.config
file, to communicate with COM+ objects. Typically, this WCF service will be hosted within IIS.
Appendix A explains how to build WCF services that communicate with COM+ objects.
The Role of WCF Contracts
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