70-487 Create a WCF Service part 2

Very often WCF is translated to ABC which corresponds to basic WCF concepts such as: Address, Binding, Contract.

A as Address...

Address provides the location of the service and transport scheme. The base address is always in this format:

[transport]://[machine or domain][:optional port]

WCF supports the following transport schemes:

• HTTP/HTTPS
• TCP
• IPC
• MSMQ
• Web Socket
• UDP

And here are a few sample addresses:

• http://localhost:8001
• http://localhost:8001/MyService
• net.tcp://localhost:8002/MyService
• net.pipe://localhost/MyPipe
• net.msmq://localhost/private/MyQueue
• net.msmq://localhost/MyQueue
• ws://localhost/MyService
• soap.udp://localhost:8081/MyService

B as Binding

Binding is a consistent, canned set of choices regarding the transport protocol, message encoding, communication pattern, reliability, security, transaction propagation, and interoperability.

WCF not only provides bindings out of the box, but allows to write custom bindings from scratch.

Here are the common (out of the box) WCF bindings:

• Basic - designed to expose WCF service as a legacy ASMX web service to support legacy clients. Offered by the BasicHttpBinding class.
• TCP - uses TCP for cross-machine communication on the intranet. It supports a variety of features, including reliability, transactions, and security. Offered by the NetTcpBinding class.
• ICP - 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. Offered by the NetNamedPipeBinding class.
• WS - a  (WS) Web Service binding, uses HTTP or HTTPS for transport and offers security, transactions and reliability over the Internet. This binding is designed to interoperate with any party that supports the WS-* standards. Offered by the WSHttpBinding class.
• MSQM - uses Microsoft Message Queueing for transport and offers support for disconnected queued calls. Offered by NetMsmqBinding class.

Each of the bindings uses a different transport scheme and encoding such as: text and binary. Having text-based encoding typically enables a WCF service (or client) to communicate over HTTP with any other service (or client), regardless of its technology and across firewalls. Binary encoding over TCP, IPC, or MSMQ yields the best performance, but it does so at the expense of interoperability because it mandates WCF-to-WCF communication.

When choosing binding for the service you can use following decision diagram:

Figure 1. Choosing a WCF binding

Programming WCF Services, 4th Edition

In addition to above bindings WCF provides three specializations of these bindings:

• BasicHttpContextBinding,
• WSHttpContextBinding,
• NetTcpContextBinding.

The context bindings adds support for a context protocol. The context protocol allows to pass
out-of-band parameters to the service.

To make things more complicated, WCF provides additional bindings:

• WS dual binding - similar to the WS binding, except it also supports bidirectional duplex communication from the service to the client;
• WebSocket binding - offered by the NetHttpBinding class, this binding is a de facto .NET 4.5 replacement for the .NET 3.0 WSDualHttpBinding as it provides a better model for callbacks over the Internet;
• Federated WS binding - offered by the WSFederationHttpBinding class, this is a specialization of the WS binding that offers support for federated securityl;
• Web binding -  offered by the WebHttpBinding class, this binding allows your service to accept simple calls over web protocols such as HTTP-GET using the REST/POX/JSON patterns;
• UDP binding - offered by the UdpBinding class, this binding provides support for the User Datagram Protocol (UDP). UDP provides no guarantee of message delivery, ordering or duplicate message detection.

C as Contract 

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 when another party has already dictated some explicit (typically proprietary) message format.

Service contract is definied by applying the ServiceContract attribute on an interface.

[ServiceContract]
interface IMyContract
{
  [OperationContract]
  string MyMethod(string text);
  
  //Will not be part of the contract
  string MyOtherMethod(string text);
}

class MyService : IMyContract
{
  public string MyMethod(string text)
  {
    return "Hello " + text;
  }

  public string MyOtherMethod(string text)
  {
    return "Cannot call this method over WCF";
  }
}

The ServiceContract attribute exposes a CLR interface (or a class) as a WCF contract independently of that type’s visibility. Applying the ServiceContract attribute on an internal interface exposes that interface as a public service contract. Without the ServiceContract attribute, the interface is not visible to WCF clients.

However it is possible to use ServiceContract attribute on the service class, it is recommended to always define a separate contract so that you can both consume it independently of the class and have other classes implement it.

Contract should have namespace defined. The contract namespace serves the same purpose in WCF as it does in .NET programming: to scope a type of contract and reduce the overall chance of a collision. You can use the Namespace property of the ServiceContract attribute to provide a namespace:

[ServiceContract(Namespace = "MyNamespace")]
interface IMyContract
{...}

Unspecified, the contract namespace defaults to http://tempuri.org. For outward-facing services you typically use your company’s URL, and for intranet services, you can use any meaningful unique name, such as MyApplication.

That's all for now. In the next part I will show how to create a WCF service.

Stay tuned!