When you dig into what is provided for you, you find a fairly straight forward implemented file called reference.cs containing an extension of the ClientBase class as well as an implementation of the service contract exposed by the service. Included in the same file is all DataContracts involved in methods provided by the service. Additionally, an application config file is created (if not already present) including a huge amount of settings – all reflecting the corresponding service settings.

The generated lot will suffice in scenarios where you start out using WCF and try to get a grasp of it. This is fine when you have a regular A calls B calls C chain of services. C exposes the DataContract D1 so B will one Service Reference to C and A will have another Service Reference to B. Actually this means that the DataContract D1 is implemented three times each one with an individual namespace.

Now trouble realises its ugly head when you occasionally need to call service C from service A. To facilitate this, a new Service Reference is added to service A providing a new implementation of the DataContract D1. Obviously, this additional implementation is truly unnecessary and moreover the namespace is different from the namespace obtained from the Service Reference to service B. This makes the two implementations of DataContract D1 incompatible even though they actually origin from the same class.

The generated configurations are also duplicated for each Service Reference and are placed in the project that contains the Service Reference. But if your project containing the Service References isn’t the project hosting your client you need to move these new configuration settings each time you update your Service Reference.

I know you can try to tweek the way Service References can be made by forcing reuse of already generated references. But it’s a hassle and to my experience it rarely works as expected.

What I suggest is to drop the use of auto generated Service References. Instead, place all Service Contracts in one project, place all DataContracts in another (or optionally the same) project and let both the services and the clients reference these projects. Next you implement your own proxy client classes, which is done fairly easy (see the following listing).

[DataContract]
public class DataContractD1
{
    [DataMember]
    public string MyData { get; set; }
}
[ServiceContract]
public interface IAService
{
    [OperationContract]
    void AddMyData(DataContractD1 data);
}
public class Client1 : ClientBase<IAService>, IAService
{
    public void AddMyData(DataContractD1 data)
    {
        Channel.AddMyData(data);
    }
}

What is missing is altering the configuration file as exemplified in the following listing.

<client>
  <endpoint
      address="net.tcp://localhost:7001/AService"
      binding="netTcpBinding"
      contract="MyServices.IAService"/>
</client>

This is basically what is to it.

WCF provides a nice group of binding types that facilitate not only old-fashioned SOAP-calls via HTTP/HTTPS, but also more efficient binding types using protocols like TCP and ICP. The elegant part is that each service can be exposed using several endpoints each featuring its own protocol coupled with several other features. The web service based binding types provide several SOAP features like REST, federated security, duplex and more. Also some of the binding types provide reliability, transactions, call backs and queuing. And if you realise that the binding types available don’t apply you can fairly easy write your own binding type since WCF is written for extendability. Alternatively, you can find a suitable provider of binding types that tend to pop up (like Noemax or RabbitMQ).

I don’t intend to go into further technical details with the specifics of WCF in this article – if interested please look here. Far more interesting is the architectural options that WCF inherently provides.

Given the fact that Moore’s law doesn’t apply anymore, since processor cores don’t get much faster, processors will tend to include ever more cores. To take advantage of this development, software needs to be able to work in parallel and in multiple threads. WCF has an interesting support for that.

Between 70% and 85% of development time is typically spent on plumbing – known as logging, transaction management, security, error handling and threading. Working on plumbing is required in order to assure secure, reliable and available solutions, but it doesn’t bring you any closer to deliver the correct business code or UI code. Amazingly, WCF has an interesting support for that as well.

Picture yourself designing services in an architectural field. Imagine that you don’t write classes – you write services declaring the features and aspects that you need. If you need to change a feature or an aspect, you change the properties declared with it and that’s it. In this world, services become a logical and physical wrapping around your precious business logic. This is an interesting and compelling concept of WCF.

The normal concept of services is that services are something that delivers a well defined access to resources. So far we’ve been used to huge Application Servers delivering Enterprise level SOA to the industry (randomly mentioning: WebSphere, Oracle SOA Suite, Oracle BEA WebLogic, Microsoft Biztalk and partly JBoss). All of them are targeted mainly for the major Enterprise level of companies requiring major economical, technical and resource investments to realise.

But what if services are lightweight, easy to host, easy to run and light on resources? Admitted, this is undeniably a compelling opportunity to bring SOA to a much wider range of applications and solutions throughout the industry. My point here is that it really points down to what WCF is about.

Actually, you can use services as a platform that goes beyond the resource service station and into the world of frontends. Nowadays, you expect your desktop client applications to be available and responsive even when querying for large amounts of data. Of course we have threads to handle concurrency and asynchronous calls but thread management and the world of deadlock is catching up. Services brings you availability and responsibility and this can easily be incorporated into your desktop client applications – interesting but not necessarily applicable in all situations.