# Sunday, 07 April 2013

Before WCF it was, of course, possible for software running on different machines to communicate. Over the lifetime of Windows there have been many technologies to achieve this: sockets, DCOM, MSMQ, .NET Remoting, ASMX Web Services and more. The problem is all of these have different APIs and different levels of capability. The goal of WCF was to provide a unified API for communication and to be able to provide a common level of service irrespective of the underlying transport.

To understand the structure of WCF and why it looks the way it does  useful starting point are the four tenets of service orientation. This is not because they are the one true definition of service orientation but because they came from the team that  wrote WCF and, therefore, give an insight to the thinking behind the architecture of WCF. Fundamentally the internals of a service should not be visible to software consuming that service and interaction between systems is based on passing platform independent messages.

There are three core concepts at play whenever you use WCF: messages, channels and encoders.

Message is a first class construct in WCF and are modeled on SOAP messages. In other words they have a payload known as the body and an extensible collection of contextual headers independent of the transport. They also support a specific header called the action header which is defined in the WS-Addressing specification. The action identifies the intent (purpose) of the message. Messages are represented by the System.ServiceModel.Channels.Message class. How messages are passed between two parties depends on the Message Exchange Pattern. One way messaging means messages are passed on one direction only. Request/Response means that there is a matching response message for each request message. Duplex means that messages are passed freely in both directions without any required causality between them. WCF supports all three of these patterns out of the box.

There are two types of channels in WCF: transport and protocol. Transport channels are probably the most obvious: they move bytes from one place to another using some transport protocol. WCF, as of 4.5, ships with the following transports: TCP, HTTP, MSMQ, Named Pipes, UDP and WebSockets. It is, however, an extensible model and, for example, there is an RabbitMQ AMQP channel. Protocol channels are designed to layer in functionality not supported by the transport, for example, transaction flow of HTTP. The three core protocol channels that come with WCF are security, transaction flow and reliable messaging. They are implementations of Web Service specification such as WS-Security, WS-AtomicTransaction and WS-ReliableMessaging and pass any required information to-and-fro using the message’s Headers collection.

Messages are objects and transport channels move bytes. Something has to translate between those two worlds and that something is called an encoder. The encoder controls the format of a message on the wire. WCF comes with four encoders: Text, Binary, MTOM and POX. The Text encoder puts textual XML SOAP messages on the wire. The Binary encoder put a binary format of the SOAP message on the wire – this binary format is WCF specific and is not designed to be interoperable with other platforms. The MTOM encoder implements the MTOM specification and is a way to transport binary payloads over SOAP without base 64 encoding them. The POX (Plain Old XML) encoder strips of the SOAP pieces and just places the body of the message on the wire and, as such, isn’t limited to XML.

Protocol channels, encoders and transport channels are composed in a channel stack controlling how messages are passed between a sender and receiver.

As you can probably tell, the channel stacks on both sides of the communication need to be compatible. Messages, Channels and Encoders make up the WCF Channel Layer.

Programming at the channel layer, however, is relatively heavy lifting and so, generally, we work at a higher level of abstraction that takes care of much of the inherent complexity. This abstraction sits on top of the channel layer and is called the Service Model Layer. With the service model layer there are only two things we have to build (we can build more if we choose to), the code that consumes the service functionality and the implementation of that functionality. All of the plumbing can be automated.


The service model layer has two concepts: endpoints and behaviors. Endpoints are those things that are agreed between the consumer and the service. Behaviors are local functionality that is not visible to the other side of the communication (e.g. how requests are mapped to threads).

You will often hear people talk about the ABCs of WCF. This is because the three component parts of an endpoint are Address, Binding and Contract.

This defines what functionality an endpoint supports: the operations and the messages they expect and may return. In WCF contracts are defined by using the [ServiceContract] and [OperationContract] attributes on interfaces or classes. Interfaces are commonly used as it allows a single service to implement many contracts.

Bindings specify the “how” of the communication: what transport protocol; how security is configured; what the messages look like on the wire, etc. In other words it defines what the channel layer looks like. There are a number of standard bindings modeling common scenarios and you can also define custom ones if you have other requirements. You can find a list of the standard bindings in WCF 4.5 here.

The address of the endpoint is where the service is listening and where the consumer will send messages. Address structure is determines by the transport protocol being used, for example HTTP based addresses start with http:// and have a machine name and potentially a port number in the address whereas MSMQ address start with net.msmq:// and contain the machine and queue name.

In the service model layer, a service is simply a class that implements one or more contracts. However, something must actively start listening for incoming messages. The ServiceHost class is responsible for instantiating the set of objects that listen at the address and dispatch the messages as method calls to the service implementation. You can either create the ServiceHost instance yourself and call Open on it (known as self hosting) or you can get the Windows Process Activation Service to do this (formally known as WAS hosting). WAS hosting is also commonly referred to as IIS hosting as the service is configured via IIS manager and the ASP.NET infrastructure.

Clients use proxy objects to make calls to services. These can be obtained in one of two ways: shared assembly and metadata.

Shared Assembly
Remember that the client must have the same endpoint definition as the service. In that case where does the client’s view of the contract come from? sharing an assembly between client and service gives both the definition of the contract. Then, using the same binding and address, the client creates an instance of the ChannelFactory<T> class (where T is the contract) and then calls CreateChannel to create the proxy.

Using a shared assembly works fine when it is reasonable for the service and client to share code but cannot be used if the service and client are different technologies and may want to be avoided if the client and service are maintained by unrelated teams. In these situations we can use metadata in the form of WSDL or WS-MetadataExchange to provide the client with a description of the endpoint which tools (Add Service Reference in Visual Studio and svcutil.exe from the command line) can consume and build the necessary code and configuration to invoke the service. Metadata is not turned on by default and must be enabled using the ServiceMetadataBehavior behavior in the service.

That then is a broad brush for how WCF hangs together. There are many other factors that need to be considered when building services but the raw plumbing of network communication isn’t something with which service developers need to get involved. Of course, there is nothing to stop developers getting involved at many of the extensibility points of WCF but fortunately that is not a requirement to get clients and services talking to each other.

Sunday, 07 April 2013 20:28:47 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Saturday, 09 March 2013

Thanks to everyone who attended my sessions at Devweek 2013 – I had a lot of fun delivering them. It was also great to catch up with old friends and make a few new ones.

As promised I have uploaded all of my slides and demos to the cloud and they can be downloaded here

WCF Preconference Workshop
Reactive Framework
Living with the GC
Workflow 4.5
WCF 4.5 (remember you’ll need to be running Windows 8 for the WebSockets demos)
What’s new in Unit Testing in VS 2012 (remember that Fakes is only in VS Ultimate SKU)

Saturday, 09 March 2013 09:12:53 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Tuesday, 05 March 2013

Thanks to everyone who attended my Devweek 2013 pre-conference session on WCF.

You can get the slides and demos here

Tuesday, 05 March 2013 08:50:40 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Saturday, 06 October 2012

“Who moved my Cheese” was how a number of people at Microsoft have characterized people’s reaction to Windows 8. In other words – “all the stuff you need is there, I know its uncomfortable that we changed things but its just cosmetic”.

To a degree this characterization is right that mostly existing functionality it there just you access it in different ways – and there is new functionality that we didn’t have before. However there is a bigger issue with Windows 8 – one of chocolate.

The Windows 8 desktop is cheese – that’s users’ familiar world prior to Windows 8. But in Windows 8 we have another way to access functionality – one that’s tablet friendly, iPad user friendly, touch friendly – that’s not cheese, that’s chocolate – people love chocolate! Finally Windows has a world that means they are not offering cheese to those chocophiles and that can only be a good thing from Microsoft’s perspective.

I’m a professional software developer basing most of my work in the Windows world. I’ve used Windows heavily since Windows 3.1 and I’ve (mostly) liked the evolution of the operating system. I currently run a big multicore machine with two high-resolution monitors for software development. The important thing for me is being able to have my development environment (Visual Studio 2012 now) as my focus but have my email, browser windows, Skype, a few Windows explorer windows, VSphere, Excel, Powerpoint and many other applications running concurrently and being able to have many of the visible at the same time correlating data between them - all of these are cheese applications.

I have been running Windows 8 for a while and really like the immersive nature of many of the “Modern Windows” (or Chocolate) applications – especially as I can run these on one monitor and have my Cheese applications running on the other monitor. And if I need to, both of my monitors can be cheese based if I have a bunch of cheese like things going on.

The problem is I just don’t like Windows 8.

It’s the damn Windows key.

If I’m in the mood for chocolate then I really like chocolate – and if you always offer me chocolate I’m very happy.

But actually I’m a savory guy – I spend most of my time wanting cheese. When I press the windows key you offer me chocolate and I select cheese – if I had to do that once I would be OK with that but every single time I want cheese you say “Aha! I think you want some chocolate” Dammit! I’ve chosen cheese every time for the last hour I obviously don’t want chocolate at the moment!

OK I’ve done that metaphor to death. The problem with windows 8 is you force me to context switch every time I want to run another desktop application. It is disruptive and painful as a user experience. If I’m in the desktop world then please, please let me start another desktop application without going via Metro.

Saturday, 06 October 2012 22:39:01 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Wednesday, 25 July 2012

Microsoft recently announced the beta of Service Bus 1.0 for Windows Server. This is the on-premise version of the Azure Service Bus that so many have been asking for. There is a good walkthrough of the new beta in the MSDN documentation here including how to install it.

So why this blog post? Well if you install the beta on a Windows Server 2008 R2 box and you actually develop on another machine then there’s a couple of things not mentioned in the documentation that you need to do (having previously spent long hour glaring at certificate errors allowed me to resolve things pretty quickly)

First a little background into why there is an issue. Certificate validation has a number of steps to it for a certificate to be considered valid:

  1. The issuer of the cert must be trusted. In fact the issuer of the issuer must also be trusted. In fact the issuer of the issuer of the issuer must be trusted. In fact … well you get the picture. In other words, when a certificate is validated all certificates in the chain of issuers must be trusted back to a trusted root CA (normally bodies like Verisign or your corporate certificate server). You will find these in your certificate store in the “Trusted Root Certificate Authorities” section. This mechanism is known as chain trust.
  2. The certificate must be in date (between the valid from and valid to dates)
  3. The usage of the certificate must be correct for the supported purposes of the cert (server authentication, client authentication, code signing, etc)
  4. For a server authentication cert (often known as an SSL cert) the subject of the cert must be the same as the server DNS name
  5. The certificate must not be revoked (if a cert is compromised the issuer can revoke the cert and publishes this in a revocation list) according to the issuers revocation list

For 1. there is an alternative called Peer Trust where the presented certificate must be in the clients Trusted People section of their certificate store

There may be other forms of validation but these are the ones that typically fail

So the issue is that the installer of Service Bus (SB), if you just run through the default install, generates a Certificate Authority cert and puts it into the target machine’s Trusted CA store – it obviously doesn’t put it in the client’s Trusted CA store because it knows nothing about that. It also generates a server authentication cert with the machine name you are installing on. This causes two issues: no cert issued by the CA will be trusted and so an SSL failure will happen the first time you try to talk to SB, the generated SSL cert will have problems generally validating due to, for example, no revocation list

The first of these issues can be fixed by exporting the generated CA cert and importing it into the Trusted CA Store ion the dev machine


The second can be fixed by exporting the SSL cert and importing it into the trusted people store on the dev machine


With these in place the Getting Started / Brokered Messaging / QueuesOnPrem sample should work fine

.NET | Azure | ServiceBus | WCF
Wednesday, 25 July 2012 17:04:54 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Monday, 02 July 2012

The demos from DEV 326 – my talk on WCF 4.5 at TechEd EMEA are available here. The session was also recorded and the video is now on Channel9 here

Monday, 02 July 2012 14:13:14 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Tuesday, 17 January 2012

To celebrate DevelopMentor’s move to offices at 120 Moorgate in London, myself and Andy Clymer are presenting an evening of C# 5 Async. The next version of the C# language has built-in support for async processing. We’ll show you how it improves over the previous models and how it works under the covers.

This event is on Monday the 6th February from 5-7 and is free to attend, just register with the DevelopMentor office on 01242 525 108 or email salesuk@develop.com

Tuesday, 17 January 2012 08:18:38 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Wednesday, 28 September 2011

Thanks to everyone for attending my sessions on the Reactive Framework and Garbage Collection at Basta 2011, you can download the demos here:

Reactive Framework

Garbage Collection

Wednesday, 28 September 2011 23:46:31 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Wednesday, 15 June 2011

Just a heads up that when self hosting the new WCF Web API. By default if you try to add the Web API references via Nuget you will get a failure (E_FAIL returned from a COM component).

This is due to the likely project types (Console, Windows Service, WPF) defaulting to the client profile rather than the full framework. If you change the project to the full framework the Nuget packages install correctly

Yet again bitten by the Client Profile

Wednesday, 15 June 2011 10:21:33 (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Friday, 04 February 2011

I have just found myself answering essentially the same question 4 times on the MSDN WCF Forum about how instances, threading and throttling interact in WCF. So to save myself some typing I will walk through the relationships here and then I can reference this post in questions.

WCF has 3 built in instancing models: PerCall, PerSession and Single. They are set on the InstanceContextMode on the ServiceBehavior attribute on the service implementation. They relate to how many instances of the service implementation class get used when requests come in, and work as follows:

  • Single – one instance of the implementation class is used for all requests
  • PerCall – every request gets its own instance of the implementation class
  • PerSession – this is the slightly odd one as it means every session gets its own instance. In practical terms it means that for Session supporting bindings: NetTcpBinding, WSHttpBinding, NetNamedPipeBinding, etc, every proxy gets an instance of the service. For bindings that do not support session: BasicHttpBinding, WebHttpBinding, we get the same effect as PerCall. To add to the confusion, this setting is the default

By default WCF assumes you do not understand multithreading. Therefore, it only allows one thread at a time into an instance of the service implementation class unless you tell it otherwise. You can control this behavior using the ConcurrencyMode on the ServiceBehavior; it has 3 values:

  • Single – this is the default and only one thread can get into an instance at a time
  • Multiple – any thread can enter an instance at any time
  • Reentrant – only makes a difference in duplex services but means that an inbound request can be received from the component you are currently making a request to (sounds a bit vague but in duplex the role of service and client are somewhat arbitrary)

Now these two concepts are different but have some level of interaction.

If you set InstanceContextMode to Single and ConcurrencyMode to Single then your service will process exactly one request at a time. If you set InstanceContextMode to Single and ConcurrencyMode to Multiple then your service processes many requests but you are responsible for ensuring your code is threadsafe.

If you set InstanceContextMode to PerCall then ConcurrencyMode Single and Multiple behave the same as each request gets its own instance

For PerSession ConcurrencyMode Multiple is only required if you want to support a client sending multiple requests through the same proxy from multiple threads concurrently

Unless you turn on ASP.NET Compatibility, WCF calls are processed on IO threads in the system threadpool. There is no thread affinity so any of these threads could process a request. The number of threads being used will grow until the throughput of the service matches the number of concurrent requests (assuming the server machine has the resources to match the number of concurrent requests). Although the number of IO threads is capped at 1000 by default, if you hit this many then unless you are running on some big iron hardware you probably have problems in your architecture.

Throttling is there to ensure your service is not swamped in terms of resources. There are three throttles in place:

  • MaxConcurrentCalls – the number of concurrent calls that can be made – under .NET 4 defaults to 16 x number of cores
  • MaxConcurrentSessions – the number of concurrent sessions that can be in in flight – under .NET 4 defaults to 100 x number of cores
  • MaxConcurrentObjects – the number of service implementation objects that are in use – defaults to the sum of MaxConcurrentCalls + MaxConcurrentSessions

In reality, depending on whether you are using sessions or not, the session or call throttle will affect your service the most. The object one will only affect your service if you set it lower than the others or you do something unsual and handle the mapping of requests to objects yourself using a custom IInstanceContextProvider

You can control the throttle values using the serviceThrottling service behavior which you set in the config file or in code

Friday, 04 February 2011 21:50:40 (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   |